I am not very familiar with the SSL Certificates and how they work.
However I succeed to install a SSL Certificate via cPanel of my shared hosting.
Please checkout this page: https://www.sportsdirect.bg/customer/account/create/
As you can see there is a problem with the certificate.
The padlock in the browser URL address is not green. Can you please tell me what can be the reason for this and how I can fix it ?
Off topic for this site.
Your web server is not properly configured to deliver the full certificate chain, see https://serverfault.com/questions/633247/ssl-error-on-mobile-devices .
Check your SSL Labs report and you will see Chain Issues: Incomplete. Your intermediate certificate:
RapidSSL SHA256 CA - G3
Fingerprint: 0e34141846e7423d37f20dc0ab06c9bbd843dc24
RSA 2048 bits (e 65537) / SHA256withRSA
... is not in your server's trust store and is not being served. Take a look at How to install an Intermediate CA cert in Apache.
Related
This question already has answers here:
SSL working in chrome but sometimes in Firefox and not on IOS, Android or Blackberry
(2 answers)
Closed 1 year ago.
I've put together a Linux (Centos 7) server to serve eye-n-sky.net.
Serving content from that site to browsers on Win10 and Linux systems works beautifully. However, when I use openssl to access the site,
openssl s_client -connect eye-n-sky.net:443
the site certificate is rejected,
Verify return code: 21 (unable to verify the first certificate)
I've concluded that the way a browser verifies the certificate is different from what openssl does. Am I on the right track?
I've tested this on three different openssl instances (Debian, Centos, FreeBSD) and have consistent results.
Openssl as a client to other sites, e.g. www.godaddy.com, microsoft.com, work fine, being able to verify the certificate against the installed CA chain.
Believing that I was missing a CA cert, I used the -CAfile option to specify the possibly missing cert, to no effect.
What am I missing? I'm guessing that openssl has a stricter verification discipline, but I don't know where that gets configured.
Thanks,
Andy
Summary: yes, eye-n-sky was providing only it's cert when it needed to include the intermediate and root certs.
However, it took me forever to figure out that my Apache version did not support including the chain in the server cert file. Instead, I had to provide the chain file separately in an SSLCertificateChainFile directive.
OpenSSL's command-line s_client utility has nothing built in to validate the server's certificate. Browsers have a built-in list of trusted certificates to verify the server certificate against.
You have to supply the trusted certificates using options such as -CAfile file or -CApath directory. Per the OpenSSL 1.1.1 s_client man page:
-CApath directory
The directory to use for server certificate verification. This
directory must be in "hash format", see verify(1) for more
information. These are also used when building the client certificate
chain.
-CAfile file
A file containing trusted certificates to use during server
authentication and to use when attempting to build the client
certificate chain.
Note the use of words such as "certificate chain". If you go to godaddy.com you'll see that the server's cert is for *.godaddy.com, but it was signed by Go Daddy Secure Certificate Authority - G2, and that intermediate certificate was signed by Go Daddy Root Certificate Authority - G2 - a different certificate. There's a total of three certificates in that chain.
Verify return code 21 is "no signatures could be verified because the chain contains only one certificate and it is not self signed", so if your CA file only had the certificate from Go Daddy Root Certificate Authority - G2 and not the one from Go Daddy Secure Certificate Authority - G2, OpenSSL would see from the server's cert itself that it was signed by Go Daddy Secure Certificate Authority - G2 and could go no further - it doesn't have that cert to see who signed it.
I am using zerossl.com website to generate an SSL certificate for my website developer.norght.com
I successfully downloaded and installed a certificate from the zerossl.com website as per their documentation. And I am able to access https://developer.norght.com securely on my devices.
My Hosting Account's SSL tab which also indicates that certificate installed successfully as below:
Now my problem is:
When I check my SSL certificate using different platforms, they are showing me this error that my certificate is not trusted on all browsers!
SSL Hopper reference:
SSL Labs reference:
I tried to troubleshoot the issue using this article https://zerossl.com/help/troubleshoot/missing-intermediate-certificate/ provided by zerossl.com but found no luck. I even try to re-install certificate, private-key, ca-bundle file but still getting the same error.
So, I search for a further tool that can help me to solve the issue on https://whatsmychaincert.com/?developer.norght.com this website. They are providing me the chain which I should use as ca-bundle, I tried that too!
I tried every solution I found around but none of them is able to solve my problem.
Anyone here if helps me with this issue it would be much-appreciated pals.
I'm aware that this question was asked about 6 months ago. So, in case you're still searching for the solution, you might wanna try the following:
Copy the ca-bundle content (cert) and paste it after your domain cert in the Certificate (CRT) field.
Yes, this means that there are 2 certs in your CRT field (domain and ca-bundle) as example below:
Certificate (CRT)
-----BEGIN CERTIFICATE-----
(domain cert)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(ca-bundle cert)
-----END CERTIFICATE-----
If this works, it's just how the cert is installed at your hosting provider.
The root cause is that the root certificate for certificates issued by zerossl.com is not included in well-known web browsers (such as Chrome and Firefox) by default as a "trusted root certificate". Therefore, you have to install the root certificate manually. This means that you have to ask everyone who wants to access developer.norght.com to install the root certificate into their web browsers manually.
If you want to enable people to access developer.norght.com without installing the root certificate manually, you have to use other certificate issuer (not zerossl.com) that can issue certificates whose root certificate is installed in well-known web browsers by default.
As the diagram below from "Illustrated X.509 Certificate" tells, the origin (i.e. root certificate) of a certificate chain must be installed in advance.
I created a Let's Encrypt certificate using SSLforFREE. It works great in the browser, but generates an "unknown certificate" error when used with an Alexa skill. Manually uploading the certificate to the Alexa service works, but it will not work as a "trusted" certificate.
Has anyone successfully used one of these as a "trusted" certificate with Alexa?
Oh, here's what you can do:
Download the contents of your fullchain.pem cert, from /etc/letsencrypt/live/<domain>/fullchain.pem on your server
On your skill config page, select the "SSL" Tab.
Mark "I will upload a self-signed certificate in X.509 format."
Paste the contents of your fullchain.pem file.
It worked for me. Not sure if chain or cert would be enough.
Dont use sslforfree. Use Letsencrypt fullchain certificates directly
Though certificates from https://www.sslforfree.com/ utilizes letsencrypt certificate chain, amazon finds an issue while tracing to a trusted certificate authority.
This is another discussion on missing certificate chains.
The solution that will work is, Use LetsEncrypt certificates directly with chained certificates to a trusted CA certificate.
For this, use certbot in order to generate LetsEncrypt certificate on your Server and follow the steps in #aldrinleal answer.
I have three files from Entrust: *.csr, *.key and *.crt.
So far:
I have brought the *.key and *.crt into a PKCS12 keystore using OpenSSL
I have imported the *.pkcs12 into a keystore using keytool
Using this technique, I am able to use an SSL connection with Jetty
However, I'm getting a Certificate Error in IE (unsecured items in Chrome).
In our case, the certificates are currently being used for domain:80 (Apache) and I'm attempting to "reuse" them for domain:8443 (Jetty).
Am I wrong in thinking that I can use these for Jetty as well? On the same IP/domain, but on a different port and webserver? My gut is telling me that one of these files relates to Entrust recognizing Apache (*.csr) and that I should have to do the same for Jetty?
Edit #1
The error goes as follow:
Certificate Error
Untrusted Certificate
The security certificate presented by this webiste was not issued by a trusted certificate authority
This problem may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage.
But yet Chrome, sees it as valid. I does have to work on IE since it's our standard.
Edit #2
Chrome doesn't complain
Nor does Firefox
Edit #3
I found our CA certificate specified in the Apache conf file. I then proceeded to concatenate our cert with the CA cert into a PKCS12 file. Then, using keytool, I generated the keystore.
I loaded it on the server, rebooted and viewed in IE. IE still shows a certificate issue.
In the concatenated file, I see in this order: our cert and then 2 other certificates.
On a side note, I called Entrust and the CSR saw no problems as he was using IE 8. We're on IE7.
Edit #4
Using this command:
keytool -list -keystore keystore -v
It shows 3 certificates (in this order):
Ours
Owner: CN=Entrust Certification Authority - L1C,
Owner: CN=Entrust.net Certification Authority (2048)
Edit 5
Solved! I guess I had a caching issue. Confirmed with colleagues.
Answer, Concatenating all my certs, including the CA cert, into the keystore solved my issue.
The port number, as stated in the comments, is irrelevant for trusting an SSL/TLS connection.
The problem is that the entire certificate chain from your certificate up to the Entrust root probably looks like this
your cert - intermediate CA 1 - intermediate CA 2 - ... - root CA
To make this work for IE you have to import not only your certificate into the PKCS#12 container, but additionally the intermediate certificates and also the root certificate. Otherwise your SSL implementation won't be able to provide the full path during the SSL handshake and thus IE has no means to build a proper chain to compare to its set of trusted root certificates.
So my advise would be to get the intermediate certificates from the appropriate web sites and importing them with keytool into your PKCS#12 key store.
Once done, IE should from then on accept without complaining.
I just installed an SSL on Plesk, and when I go to https://www.example.com in Chrome, I get the error below:
This CA Root Certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities Store.
Sort of defeats the purpose of having an SSL. Any idea how I can make this message go away?
I bought the SSL from GoDaddy, which I would expect to be a trusted authority.
This issue occurs because the issuing authority has signed the server certificate using an intermediate certificate that is not present in the certificate base of well-known trusted certificate authorities which is distributed with a particular browser. In this case the authority (GoDaddy) provides a bundle of chained certificates that should be chained with the server certificate to address this issue of lack of trust. Unfortunately, GoDaddy does not provide any documentation on this front. You should have received two different certificates from GoDaddy, one for your server, and the bundle. Depending on your server, this is what the configuration would look like:
For Apache:
Specify each certificate in its own directive:
SSLCertificateFile /path/to/cert/www.example.com.crt
SSLCertificateChainFile /path/to/cert/bundle.crt
For Nginx, documented here:
Both certificates should be concatenated, first the server, then the bundle:
cat www.example.com.crt bundle.crt > www.example.com.chained.crt
And then use www.example.com.chained.crt in your server ssl_certificate directive:
ssl_certificate www.example.com.chained.crt
GoDaddy is recognized on Windows operating systems, because the GoDaddy root certificate is pre-installed on Windows. But GoDaddy will not be automatically recognized in many contexts and would need to be manually configured by users (which is not a trivial task). IPhone, for example, will not trust GoDaddy certificates out of the box. You may consider getting certificate from established certificate authorities such as Verisgn or Thawte, but they will be more expensive.
#John: GoDaddy is a registrar/webhost, I believe their certificates are just reseller certs. You don't need to go expensive to get compatibility as #Jaro suggests. I've deployed several RapidSSL certificates that are recognized by Chrome/iOS and Safari/iOS without user intervention and are much cheaper than the higher-insurance certificates like Symantec/VeriSign.
The only way to make that message go away, is by buying a real certificate from a trusted authority.