We purchased an SSL certificate through DNSimple and installed it on our Heroku SSL endpoint. Now navigating to the app via SSL works fine on Chrome and Safari, but Firefox shows a "This connection is untrusted" error. Why would an SSL cert be untrusted by Firefox only?
We figured out the problem:
The Heroku docs point to the following bundle.pem file, which DOES NOT WORK FOR FIREFOX:
https://knowledge.rapidssl.com/library/VERISIGN/ALL_OTHER/RapidSSL%20Intermediate/RapidSSL_CA_bundle.pem
The CORRECT bundle.pem file is at:
https://knowledge.rapidssl.com/library/VERISIGN/INTERNATIONAL_AFFILIATES/RapidSSL/AR1548/RapidSSLCABundle.txt
as indicated on the RapidSSL site.
Heroku docs need to be updated. Hopefully this saves someone else some time..
UPDATE: We reported this to Heroku and they updated their docs, so this is no longer an issue.
Mozilla include a list of Certificate Authorities (CA) with their products, as do Google, Apple, Microsoft and others. If your certificate can be traced back to one of these than the browsers will trust it. If not, you have to add an exception, or import the certificate into your browser.
The list of included CAs is created at the whim of the different browser makers. Some include the root CA for your certificate, and it seems Mozilla do not.
You can get a list of CAs included by Mozilla here. Check your certificate details. If the root CA is on this list file it as a bug with Mozilla. If it's not you could try asking them if they'll include it for the next release.
It's a problem of rapidssl but not yours.
you should not only provide the server certificate, but should concat your server certificate and INTERMEDIATE ca certificate.
do
$ cat ca_certificate.crt >> server_.crt
and restart your nginx.
you can find the ca certificate on what site you buy certificate.
Related
I've configured an NGINX reverse-proxy with SSL certificate and it works fine in Chrome and IE, but give me an SSL error (SEC_ERROR_UNKNOWN_ISSUER) in Firefox.
Why is that?
I've just found another answer to a similar problem that explains that this happens if the certificate chain is not fully sent by the server (or in this case the load balancer).
This other answer explains that Chrome looks for this missing chain certificates by itself while Firefox does not. Actually Firefox caches intermediate certificates from earlier connections to other sites, but in my case since I'm mostly using Chrome, Firefox didn't had any cache of these Sectigo (Comodo) root certificates, that's why I was getting the validation error.
When I purchased my PositiveSSL certificate I've received both the "crt" file for my domain but also a "ca-bundle" file which is the certification authority bundle. Both these files should be concatenated (first my certificate, followed by the certificates for the authority chain), and this combined file is what should be configured as ssl_certificate in NGINX.
Shortly after we renewed our SSL certificate on Heroku, all Mailgun webhooks (post requests made by Mailgun to our endpoint so that we can track email deliveries) started failing with the error "Could not connect to remote server: HTTPS certificate validation failure".
How could we check whether this issue might be caused from misconfiguration of our SSL certificate rather than an issue on Mailgun's side?
Here are the details of steps we took to renew and install the certificate:
We followed these instructions to generate a new private key and
CSR.
After uploading the CSR and downloading the CRT file on Namecheap, we ran heroku certs:update as described here.
These are the checks we made to verify successful installation of the new certificate:
Navigated to our site with Chrome, Safari, and Firefox and checked
the certificates. Everything looks right.
Ran heroku certs. The certificate looks good and it is shown as trusted.
Used the online checker here and here (as watery suggested in the comments). Everything is green.
Verified with Namecheap that the intermediates were setup correctly. They basically confirmed that the output of openssl s_client -showcerts -connect www.mysite.com:443 looks right.
A potential lead:
After running brew update openssl and rvm install 2.3.1 --disable-binary, the following was observed. Running Net::HTTP.get URI('https://www.google.com') works, while the same command with our URL fails with OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed.
However, running Net::HTTP.get for our URL on a freshly installed linux Docker container
does not fail, so there may be additional environment factors.
Any leads to the likely cause of this issue, or suggestions for steps we can take to find such lead, are much appreciated.
The issue was found as described in my other related question. COMODO added a new root called COMODO RSA Certification Authority instead of the previous COMODO Certification Authority. The new root was not whitelisted by Mailgun. I contacted support, and they are working to whitelist it.
I think this is related to SSL chaining issue. Please check the ssl certificate you are using must be in order of domain_cert > root_cert > intermediate_cert(they can be multiple). You need to concat certificate in fixed order to fix this issue. I hope this helps you. For more you can test you website ssl in this https://www.ssllabs.com/ssltest/
I have installed SSL Certificate manually that I had brought from Godadday. It installed successfully but it shows self signed certificate which is not trusted or displays cross on https.
What is the solution ?
It is showing because it does not recognized the certificate that you get from Godaddy.
The CSR certificate has to upload on your site and make changes on apache config file.
Make sure your CSR file should not match with the private key that you submitted to verify your site.
Installing a SSL certificate requires some server administration knowhow, especially updating web server configuration.
DigitalOcean has a great tutorial on how to install a SSL certificate from GoDaddy: https://www.digitalocean.com/community/tutorials/how-to-install-an-ssl-certificate-from-a-commercial-certificate-authority#example-ca-2-godaddy
Maybe it helps.
To check if you installed it correctly, you can use Qualys SSL Server Test at https://www.ssllabs.com/ssltest/index.html
I have installed a ssl certificate via WHM on one of my domain. Site is working with https://xyz.com.
However it is not working with https://www.xyz.com. I have checked the certificate and it is for www version as well. After some research it appears to be incomplete chain issue. I had no idea how to resolve this. Please help.
A certificate can contain a special Authority Information Access extension (RFC-3280) with URL to issuer's certificate. Most browsers can use the AIA extension to download missing intermediate certificate to complete the certificate chain. But some clients (mobile browsers, OpenSSL) don't support this extension, so they report such certificate as untrusted.
You can solve the incomplete certificate chain issue manually by concatenating all certificates from the certificate to the trusted root certificate (exclusive, in this order), to prevent such issues. Note, the trusted root certificate should not be there, as it is already included in the system’s root certificate store.
You should be able to fetch intermediate certificates from the issuer and concat them together by yourself. I have written a script to automate the procedure, it loops over the AIA extension to produce output of correctly chained certificates. https://github.com/zakjan/cert-chain-resolver
When generating a self-signed certificate using keytool, can I use an IP address for the Common Name?
Once I generated the certificate, I exported it so I can install it in my clients/browsers. In Windows, I ran mmc.exe and added it as a Trusted Root Certificate Authority.
However, when I navigate to the IP address in my browser, it is still an untrusted connection. I ensured Tomcat had all the correct Connector settings.
Am I doing this correctly? do I need to be my own CA? How can I use SSL for development purposes? I'm still trying to understand SSL completely.
First question: if you'll be connecting by IP, then yes.
Second question: No, you don't install your self-signed certificate as CA, you just add exception when your browser warns you that it's self-signed.
You can set up CA — you generate root certificate first, install it in the client, and then generate CSR and then server certificate from it (see e.g. this), but for development purposes this is a complete waste of time.