I have been managing Let's Encrypt's SSL certificates for a domain.
Now I am moving to Amazon API gateway. I will be using the AWS Certificate Manager to generate HTTPS certificates for the root domain and a bunch of subdomains.
If I make the transfer, what happens to my current HTTPS certificate which is associated with my domain. If browsers suddenly start seeing a new HTTPS certificate for a domain, for which they had been getting a different HTTPS certificate until now, would this be a problem?
Also, once I make the shift, what do I do with my current (manually managed) Let's Encrypt certificate? Is there a way to permanently void it?
Szabolcs Dombi says
You can have multiple valid certificates for the same domain at the
same time. Moving from one certificate issuer to another should not
cause a problem.
Toby Osbourn says
SSL certificates don’t last forever, most of them need to be renewed
on a yearly cycle and occasionally you will want to change the type of
the SSL certificate mid-cycle.
Since you are replacing certificates, I suggest you to back up the ones you have.
Once you have backed up the old certificates, just overwrite the .crt and .key files with your new ones. Then, reload your web server so it knows to look at these new certificates, and you should be good to go.
If it's within your interest to know more about how to Generate SSL certificate using Amazon Certificate Manager (ACM), I suggest Barguzar, A. (July 2018). Building Serverless Python Web Services with Zappa. where one can read a good step by step guide. See an excerpt of it below:
ACM is a service that manages and creates SSL/TSL certificates for
AWS-based services and applications. An ACM certificate works with
multiple domain names and subdomains. You can also use ACM to create a
wildcard SSL.
ACM is strictly linked with AWS Certificate Manager Private
Certificate Authority (ACM PCA). ACM PCA is responsible for validating
the domain authority and issuing the certificate.
You can have multiple valid certificates for the same domain at the same time. Moving from one certificate issuer to another should not cause a problem.
This also means that if you create a new certificate the old one still can be used unless it already expired.
Related
I am working in Ec2 instance. I have connected my php files like http://13.57.220.172/phpinsert.php. But it is not secured site. So i want to convert http into https://13.57.220.172.
I have cloudflare ssl. When i try to add ssl certificate. It shows
com.amazonaws.pki.acm.exceptions.external.ValidationException: Provided certificate is not a valid self signed. Please provide either a valid self-signed certificate or certificate chain. Choose Previous button below and fix it.
i have enclose the image with it.
So how can i get the self signed certificate. is there any online tool available.
I think the error message your seeing has to do with this sentence:
If your certificate is signed by a CA, you must include the
certificate chain when you import your certificate.
from https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html.
Since it sounds like you're not yet in "production" mode, I'm guessing you're not particularly attached to your existing certificate, but just want a certificate to be able to do HTTPS on your web server (and don't really care if it's self-signed).
If you want to use AWS Certificate Manager, I think it would be easier to just let them (AWS) issue you a certificate instead of trying to import one from somewhere else. AWS doesn't charge anything for certificates. https://docs.aws.amazon.com/acm/latest/userguide/acm-billing.html
Even if you get the certificate setup in AWS Certificate Manager, that's not going to be installed directly on your EC2 instance, but rather (most likely) on a load balancer in front of your web server, which will add a little complexity to your setup. https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html
If all you want to do is use HTTPS on your web server, Let's Encrypt (also free) is probably a simpler option. If you are using AWS Linux 2, there are instructions for getting a certificate here - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html
Well, add to the points which #jefftrotman has already mentioned.
If your expectation is to just secure your IP address using HTTPS you can achieve that using the below approaches:
A SELF SIGNED certificate that you can create using OpenSSL.
You can also get an SSL certificate from a trust signing authority like (GoDaddy or VeriSign) or Let's encrypt.
The only requirement in the second point is that for getting a certificate from a valid signing authority you need to have a domain name like "myphpapp.com" and then use this domain to get the SSL certificate.
The below details are in case you want to use AWS ACM(Amazon Certificate Manager)
If you prefer ACM, you can get the free Public SSL certificate which you can map to the IP address and your web application will be secured.
If your requirement is to add SSL certificates (like PEM files) to a web server like
NGINX or Apache then you first need to create a Private CA using in ACM and then you using this CA you will be able to create Private SSL certificates. After creating those you can export the files and add those files to the configuration file. (try to use Amazon Linux 2) ec2 image for ease.
I'm developing an app for a non-tech client that has outsourced the backend to another developer. We'll be launching the app under 7 different branded app, over a series of weeks. Each app is exactly the same, sans for the domain the API end points are on (IIS hosted).
As part of our security, we validate the SSL certificate when we connect to the API, and ensure the key returned by the API server matches our hardcoded version of it, as to prevent man-in-the-middle attacks to sniff our REST calls. We have this functioning now for the current server (1 of 7 to be rolled out).
We've asked the backend guys to provide the certificates for the remaining 6 sites, so we can deploy the apps with the expected keys. However, they claim that as they will be rolling out the sites individually over the coming weeks, each time they bring a new a new site online, they said they are "updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
Now whilst I'm no dummy, I'm also not a server admin, and only 99.9% sure that the SNI configuration to support another cert on the server, will not have any affect on the current certs already hosted for the existing domains. As a result, I wanted to explicitly confirm that the cert key we're validating as part of the SSL auth, is not going to change with each revision of the SNI config. The backend devs have essentially shut us down claiming we're paranoid, and going "beyond what is required" and to not expect "the same security a the major players offer" (as I mentioned that any decent commercial app validates its connection).
Is anyone able to confirm (or correct) my understanding of SNI as it relates to the certs, primarily that as they bring new sites online, that changes to the SNI have 0 impact on the existing certs for the current sites?
Edit: Whilst the use of multi-domain certs would regenerate the key, we can assume that they could generate/re-issue a multi-domain cert now in advance of the domains coming online. The question of if it's affected by the SNI config remains.
"updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
This is a weird argument. The point of SNI is that they can have multiple sites (domains) on the same IP address where each has its own certificate. If they add a new site only a new certificate for the new domain need to be created and all the other certificates will continue to work: a client using SNI will tell which site it wants to visit and the server then can pick the appropriate certificate. If they instead could not rely on SNI then they would have to use certificates which cover all sites on the same IP address.
So while it can be that they have some process which requires this kind of reissuing certificates it is not a requirement because of use of SNI, but only because they designed their process this way.
I'm writing a utility Mac OS X app that basically acts as a web server accepting incoming HTTP requests (think of it as a mock REST API server). I want to be able to support HTTPS, but ideally I'd like to remove the requirement for my users to have to purchase their own SSL certificates.
I've been thinking a little on how I might achieve this. Let's say I register a domain called myapp.com. I then purchase an SSL cert for myserver.myapp.com that is signed by a registered CA. I ship my app with those SSL cert details embedded within it. All my users have to do is update their /etc/hosts file to point myserver.myapp.com to whatever IP address my app is installed and running on.
In fact, by far, the most common scenario would be my app running on the same machine as the client, so I'm considering updating the main DNS entry for myserver.myapp.com to point to 127.0.0.1, and most users wouldn't have to change anything.
So, that's the basic theory. What have I missed that would make this an unworkable plan? A couple of things that have crossed my mind:
I could use a self-signed cert. However, many SSL clients barf (or throw up warnings) if the cert doesn't have a valid CA chain. I'm happy to pay the money for a real cert to alleviate this inconvenience for my users.
I would be embedding the private key for my SSL cert into my app. In theory, someone could extract that and use it to impersonate my app. I guess my reaction is "so what?" My app is a small productivity app, it isn't an e-commerce site. It doesn't collect sensitive info. It literally just simulates web server responses so devs can test their apps.
Any advice/feedback would be greatly appreciated. Thanks.
This won't work - but for nontechnical reasons.
Distributing an SSL certificate to your users along with its associated key will violate the issuance terms of your SSL certificate provider, and they will revoke the certificate when they discover what you have done. (This happened, for example, when Pivotal tried to offer SSL service for developers through sslip.io.) This will, of course, cause your application to stop working.
If your users have administrative access to their machines, they can create and trust their own self-signed CA using Keychain Access. Once they have done so, they could create a certificate (again, using Keychain Access) and insert that into your application to enable SSL.
As said in the other answer you can't ship the same certificate for everybody. What you could do is generate different for everybody:
The application ask them the domain name they want to use (a domain they must own, like myapp.example.com)
The application use the ACME protocol to get automatically a trusted certificate from let's encrypt
Note: you can provide them subdomains of a domain you control (like [clientid].yourappname.yourdomain.com) ONLY of you can register yourappname.yourdomain.com in the public suffix list (because let's encrypt have rate limits)
I have been using a wildcard SSL certificate for several of my company's B2B websites for some time. Recently, we noticed that Google Chrome started displaying a red unlocked lock with HTTPS crossed out for all of these websites. The solution I found was to reissue the certificate from the provider (Network Solutions). So, I did this, and updated the certificate for each of the websites, and the Google Chrome issue went away (HOORAY!). However, when visiting any of these websites in Firefox, it displays a security message stating the website is using an invalid security certificate:
How can I resolve this so that our users are not confused when visiting these websites?
P.S. These websites are running on IIS6.
It looks as if the certificate chain is incomplete and, thus, Firefox (and likely other browsers) cannot verify the site certificate. Normally browsers store intermediate certificates they have seen in the past - that might be a reason why it works in Chrome.
You can test using https://www.ssllabs.com/ssltest/analyze.html.
Depending on the server software (here, for Apache httpd and other servers which read the certificate in PEM/DER format), you can just paste the intermediate certificates together with the certificate in one .pem file (which is used as Certificate file).
The chain (intermediate certificates) is/are normally provided by your CA. In your case you could also use Chrome the review the certificate and then store/extract all intermediate certificates from the certificate view.
You can get this certificate is not trusted error if server doesn't send a required intermediate certificate.
Firefox automatically stores intermediate certificates that servers send in the Certificate Manager for future usage.
If a server doesn't send a full certificate chain then you won't get an untrusted error when Firefox has stored missing intermediate certificates from visiting a server in the past that has send it, but you do get an untrusted error if this intermediate certificate isn't stored yet.
You can inspect the certificate chain via a site like this:
http://www.networking4all.com/en/support/tools/site+check/
I followed the instructions at enter link description here, to import the intermediate certificates.
In IIS, there is an option under Directory Security to "Enable certificate trust list". I enabled it and added the "AddTrust External CA Root" to the CTL certificates list and this appears to have fixed the issue.
I have created a pem and crt file to use with my EC2 instance on AWS. I have 2 questions here:
1) The configuration instructions say: "Normally, at this stage you would submit your CSR to a Certificate Authority (CA) to apply for a digital server certificate." To whom do I send the certificate and how do I do it? Sorry, first time for me.
2) I am horribly confused about the uploading process to AWS. I have seen articles on uploading to a load balancer and uploading to IAM. I am using an EC2 instance and not, as far as I know a "load balancer" and I do not use IAM security. So how should I upload and what do I need to do?
Yours very confused seeking help ...
To get an SSL certificate signed you need to submit it to a trusted company, known as a Certificate Authority (CA). Think of your CSR like a blank cheque, nobody will trust it until it's signed by someone trustworthy.
There are commercial CAs which vary greatly in price, alternatively there are free CAs such as CACert (which I haven't used). The general process is: upload your CSR to the CA's site & the CA will provide a signed certificate.
If you want more information on what a CA's role is wikipedia is a great place to start, excerpt below:
In cryptography, a certificate authority or certification authority (CA) is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made by the private key that corresponds to the certified public key. In this model of trust relationships, a CA is a trusted third party – trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. Many[quantify] public-key infrastructure (PKI) schemes feature CAs.
For serving SSL traffic you have two options:
A common web pattern is to "Terminate SSL at the load balancer", which just means the load balancer will host and serve the SSL certificate, then simply sends traffic to the web server (your EC2 instance) via http. This is generally considered safe as the last hop is within your infrastructure.
If you want to go without a load balancer you'll need something on the EC2 instance to serve the SSL certificate. Here again there are plenty of options but generally installing Nginx or Apache on your instance to sit in front of your app works well.
Example configuration for Apache & Nginx are plenty & you should be able to find specific instructions for what-ever language & framework you're using but they're all fairly similar.
The play framework doco has examples for both Apache & Nginx sitting in front of a web app running on the same (EC2) server on port 9000 which should work for pretty much anything running on that port.
Plenty of reading to get you on your way, hope it helps!