SSL Error: Cannot verify server identity
Phone browsers have less trusted root and intermediate certificates than many desktop browsers. This can make your https site look good on the web but fail on mobile devices. Errors like “unable to verify the identity of the server” and others along those lines can show up. This is because the certification chain can not be verified. Doesn’t matter what supplier of SSL certificates you use they all end up in a few root certificates that are shipped with browsers and operating system as trusted certificates.
Many certificate re-sellers have their root certificates further down that chain than others. If the chain can’t be traced back to a trusted certificate the warnings will show up. That will not effect the actual encryption of your website, self signed certificates for example still encrypts the traffic, but it will look bad. People can interpret that as a security risk, like a man in the middle attack, or as just low quality.
In this example I have setup a website on a Apache server with a certificate bought from GoDaddy. I haven’t installed the intermediate certificate. Any desktop browser can follow the chain, since it has a different set of trusted certificates, but the iPhone or Android devices can not since they don’t have this certificate. There is a hole in the chain between our website certificate and the trusted one that the device have. By plugging that hole with a valid certificate that our certificate references and in turn references the trusted certificate that the device have we can complete the chain and get rid of the problem.
As mentioned above this example uses a Apache web server running on Linux and a GoDaddy certificate. The procedure will be different with other web servers and certificate suppliers but the principal is the same. When your certificate is delivered always check if there is intermediate certificates included.
So in the zip file that your GoDaddy certificate comes in there is a file named dg_bundle-g2-g1.crt, this is the certificate that your web site certificate is derived from and sits between that and the trusted certificate higher up in the chain.
So on my Apache server I bring up the file /etc/httpd/conf.d/vhost.conf
[bash]<VirtualHost 172.30.31.95:80>
ServerAdmin webmaster@somesite.com
DocumentRoot /var/www/html/somesite.com
ServerName http://www.somesite.com
ServerAlias somesite.com
ErrorLog logs/somesite.com-error_log
CustomLog logs/somesite.com-access_log common
</VirtualHost>
<VirtualHost 172.30.31.95:443>
ServerAdmin webmaster@somesite.com
DocumentRoot /var/www/html/somesite.com
ServerName http://www.somesite.com
ServerAlias somesite.com
ErrorLog logs/somesite.com_ssl-error_log
CustomLog logs/somesite.com_ssl-access_log common
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/somesite.com.pem
SSLCertificateKeyFile /etc/pki/tls/certs/somesite.com.key
</VirtualHost>[/bash]
As you can see we have two ports open, standard port 80 for http and https on port 443. The 443 have certificate along with it’s private key configured. Upload the intermediate certificate to the server and copy it into the same folder (/etc/pki/tls/certs) as the other certificate files. Make sure that the apache server have access to it.
[bash]sudo chown -R root:www /var/www[/bash]
Then add the bundle file in the ssl config in vhost.conf by adding this line just below the SSLCertificateKeyFile line.
[bash]SSLCertificateChainFile /etc/pki/tls/certs/gd_bundle-g2-g1.crt[/bash]
Restart Apache
[bash]sudo service httpd restart[/bash]
Now the certificate chain can be completed on the other devices as well and the error/warning will be gone!
Hi Kristofer, your sugestion didn’t worked for me. Could you take a look at my case?
LikeLike
What issue are you facing?
LikeLike
I have set this:
SSLCertificateFile /etc/pki/tls/certs/*********.crt //provided by godaddy
SSLCertificateKeyFile /etc/pki/tls/certs/*********.key //my key
SSLCertificateChainFile /etc/pki/tls/certs/gd_bundle-g2-g1.crt //provided by godaddy
It works fine with Android devices, but safari doesn’t recognize as a valid certificate ( the lock is not green as in http://www.apple.com )
LikeLike
What is your url?
LikeLike
It’s http://www.wearatar.com
LikeLike
Hi,
You will never get that green “Apple, Inc [US]” equivalent with your certificate. That is a special type of certificate called “Extended Validation SSL Certificate” which comes at higher price then regular certificates. Checking your site everything checks out and your encryption is working as it should. If you try https://google.com in the same browser you will see that not even google have that green validation bar. What you have setup so far is considered secure and internet standard.
/Kris
LikeLike
Kristofer, thank you very much for clarifying it to me. I thought I was doing something wrong.
Have a nice day =)
LikeLike
Glad I could help! 🙂
LikeLike
Just on the line with Godaddy Technical SSL support having this issue:
You made Godaddy – my supplier since over 10 years – bluster and let me wait for 45 minutes on the line while are fixing the problem, hopefully not just for me. Apparently they knew about this exact post but first the support expert said he NEVER heard of this issue. In an IOT and Mobile world, this has surprised him. Thanks a lot for this. I’m on the Linux Ultimate shared hosting solution and thus no direct access to the Apache conf. Armin
PS: I am still waiting on the phone and they are trying to fix it… And most sites will go ALL SSL for multiple reasons including security, confidentiality and a higher Google Ranking for the site. This not working on mobile devices is unacceptable. 80% of my future customers are/will be mobile like IOS. Why the heck the mobile OS makers cant do things exactly the same way with Certs and CA chains as on desktop, remains a mistery to me. Mobile OS are still a lot of sh..e in many ways, I suppose. Or just dumb programmers…?
LikeLike
Happy it helped! That’s the problem with shared hosting, the provider is so used to that the customer doesn’t know so they never listen.
LikeLike
Actually I asked them if they could confirm if yes or no the added your instructions to Apache cons and now the request is open for 4 hours
Neither they confirmed or told me a fix
Until when …
Keep fingers crossed
For my sites to be ssl only is primordial and no
Mobile support is No Go
LikeLike
Just a correction, its not dg_bundle-g2-g1.crt, Should be gd_bundle-g2-g1.crt
LikeLike