Wildcard certificate causes warning on Google Chrome only

I have a company.sv domain and recently purchased a RapidSSL wildcard certificate, I installed it and tested it with many browsers(Firefox, Chromium, Chrome, IE) and SSL checking tools, it worked fine on every one except on Google Chrome in neither Windows, Linux and Android.

Every time I access the website through Google Chrome it show a warning saying that I tried to access www.company.sv or whatever.company.sv but the server identifies itself as **.company.sv*. If I continue despite the warning and click the red lock, it tells me that I'm connected to a server that is only valid inside my network and can't be validated through an external certification entity.

I contacted the certificate re-seller's support service but they couldn't give me a straight answer about what was the problem. I've been wondering if it has something to do with TLD being .sv. I've also checked the Chromium source code but it seems kinda pointless since the certificate works flawlessly on Chromium.

Maybe it's worth mentioning that I'm using NGINX on a Ubuntu 12.04 Server and that I tested a free single-domain certificate from Comodo before purchasing the wildcard one.

It sounds like you forgot to install the intermediate certificate bundle on your web server. Visit the certificate vendor's web site to download the intermediate bundle.

For nginx, this must be concatenated with your certificate and placed in the ssl_certificate directive, for instance:

# cat company.sv.crt ca_bundle.crt > company.sv.chained.crt

And in your nginx config:

ssl_certificate /etc/path/to/company.sv.chained.crt

I suspect that you have the site name in the Subject CN= field, it needs to be in the subject alternate name field for Chrome to accept it. if you display the certificate in the browser, or with openssl x509 -in certificate-file -text

See:

this blog post

These baseline requirements mandate that certificate authorities always include at least one Subject Alternative Name in the SSL certificates they issue, this means that today an application doesn’t need to look in both the Common Name and the Subject Alternative Name they only need to check the latter.

Currently most Certificate Authorities will include the first DNS Name from the Subject Alternative Name in the Common Name field also but this is done primarily for legacy reasons and at some point in the not so distant future will stop.

this discussion

Certificates have two ways to express the domain/IP they're bound to - one which is unstructured and ambiguous (commonName), and one which is well-defined (subjectAltName). In the absence of any subjectAltNames, Chrome currently falls back to comparing the domain against the commonName, if present.

This proposal is to remove that fallback path; in effect, requiring a subjectAltName. Ideally, we would do this for all certificates (publicly trusted and privately trusted), but if there are concerns about compat risk, we can restrict it to publicly trusted certificates.