Here is my dilemma. Currently we run quite a few server on AWS EC2 service. Before my time, they used to configure Server images with the SSL certificate on them. Now, the certificate is about to expire and we need to replace the old one with the new one. I have read documentation on AWS in regards to uploading new certificate to IAM but it is very confusing. Is there any way, for example, using Power Shell commands to upload the new certificate to the existing servers?
Thanks in advance.
If you have certificates that are expired on existing instances and NOT on an Elastic Load Balancer, then you need to update each server as needed, on that server.
It is not an IAM type server certificate.
So you need to touch each server and upgrade. If you have AMIs for each server, you may need to create new AMIs after upgrading the certificate.
See Install certificate with PowerShell on remote server for some suggestion on PowerShell methods of installing a certificate file remotely.
Depending on your budget, you could consider using an ELB even for one instance, and installing the SSL cert there. It makes it easier in the long run to manage certs at the ELB level, rather than at the server/AMI level
Related
I have 2 aws accounts having their own RDS instances(not publicly accessible) with db engine as postgresql 12.5. I downloaded RDS certificate from "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem".
I am using JDBC(postgresql driver) with properties ssl=true and sslrootcert="path to above certificate" to establish secure connections.
My questions:
This certificate is same for both aws accounts which have different names, so how does it work , Does ssl hand shake verifies that client(jdbc connection) is talking to rds.amazonaws.com or the actual RDS instance which has separate name ?
RDS certificates are replaced every 5 years, i.e. applications also have to update the certificate every 5 years or sooner than that once new certificate is available from RDS, is this correct ?
Q1.
Yes, its same for all accounts. You can download it from docs here. Its about the instances as explained in the docs:
Using a server certificate provides an extra layer of security by validating that the connection is being made to an Amazon RDS DB instance.
Q2.
You can update before actual expiration few months before. Last year it happened as explained here:
The server's certificates are each different. Each server sends its own cert when you ask to establish a SSL connection to it. The thing you download is the cert for the authority which signs each of the server certs. You (Or your JDBC) use it to verify that the per-server certs are genuine.
We host a website in our company.
A certificate was issued to www.ourdomainname.com from the company IT department.
Now we want to move the website to azure and install the certificate there.
I already exported the certificate with private key exported set to true from the server.
1.) What will happen when the certificate is installed on azure when it is also installed on our company server?
2.) What will happen when the website on our server is stopped in the server and the certificate is then imported to the azure website?
3.) How can I guarantee a soft transition time without any break?
The aim is:
Website on the company server going to be deleted and the website on azure is used instead.
What will happen when the certificate is installed on azure when it is also installed on our company server?
web site will be available via SSL in Azure too.
What will happen when the website on our server is stopped in the server and the certificate is then imported to the azure website?
web site on your server will be inaccessble.
How can I guarantee a soft transition time without any break?
it is more about DNS management. There is no much work with SSL. You just install SSL on both internal and Azure servers, so clients can access both. Test if web site on Azure works the same way as on your internal server. Then point all clients (via DNS) to a web site on Azure. When all clients move and there are no references to internal server, you can safely shutdown it.
The SSL Certificate which was exported from the current server has to be imported in Azure. The format of the certificate has to be PFX.
Now, in the DNS Management , you need to edit the A record for the URL and point it to the IP address of Azure. This will make sure that any request made will be handled by Azure .
I have an application running on Wildfly 10 in a domain setup with more than 10 machines. Clients consume REST webservices using SSL authentication, in this scenario we will be adding clients on a daily basis so it is important to be able to propagate changes on the Truststore to the whole server group.
It's not an option to centralize the truststore in one machine due to concurrency levels.
I would like to know if there is a way to achieve this using the CLI or any other alternatives.
Thanks in advance!
Given that Wildfly does not support reloading the truststore at runtime (see https://access.redhat.com/solutions/482133), you would copy the truststore file to all servers (by hand, by script, by Puppet/Ansible/your DevOps tool), and use CLI to restart the affected server groups in the domain.
See also https://github.com/wildfly/quickstart/tree/10.x/helloworld-war-ssl for an example to implemet SSL auth. Basically all clients get a certificate from your own CA, which you add to the truststore once. Then use RBAC for the authorization.
I have a website running on a shared hosting provider (ie. without SSH access). CPanel is installed. Is it possible to install (and just as importantly, renew) a Let's Encrypt certificate automatically without SSH access? Perhaps a CPanel plugin or cron job (for automatic renewals)?
follow this tutorial to for auto renewal https://neurobin.org/docs/web/fully-automated-letsencrypt-integration-with-cpanel/
You can install Lets encrypt SSL using cPanel ssl/tls -->Install and Manage SSL for your site (HTTPS) --> Manage SSL Sites. To renew certificate you need to regenerate it using your account key and Certificate provided by Lestencrypt in first time. I have done successfully that on GreenGeeks shared hosting help of http://wayneoutthere.com/how-to-lets-encrypt-cpanel-shared-hosting/. You can use https://zerossl.com/free-ssl/#crt to generate Certificates and copy to Cpanel.
You can try to install SSL on your domain through cPanel >> Security >> SSL.
If you are unable to find this in your cPanel then you need to install SSL on your domain through WHM.
You will need Let's Encrypt itself to be installed on the server before running any plugin or crontab job (specially that).
I doubt there is a way to do that without SSH connection, specially on a shared server.
I'm developing an application on Azure VM and would like to secure it by using the wildcard SSL certificate that I'm already using with my main domain. The SSL cert works with any *.mydomain.com and the application on Azure VM is accessible through myapplication.cloudapp.net
Based on the research that I've done, CNAME should be the best option to do that (I can't use A record since we need to shutdown the VMs every week and turn them back on the next week and will lose the ip addresses).
My two questions are:
How can I have myapplication.cloudapp.net be shown as subdomain.mydomain.com?
Will doing that make it possible for wildcard SSL certificate to be used for Azure application too?
How can I have myapplication.cloudapp.net be shown as
subdomain.mydomain.com?
Yes - this is just the CNAME forwarding and ensuring that the appropriate SSL certificate is installed on the server.
Will doing that make it possible for wildcard SSL certificate to be used for Azure application too?
Well as you're already exposing the Application through the VM - this should happen seemlessly.
Just a word of caution, you mention that you're using the certificate on the main domain, but haven't mentioned where you're using this. Be aware that, out-of-the-box, you can only assign one SSL per HTTPS endpoint. You can enable multiple SSL certificates on an Endpoint for Azure / IIS using Server Name Identification and can be enabled directly or automatically. If you do take this route, remember to configure your SNI bindings first, then apply the default binding - it kinda screws up otherwise.