3

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.

Rafael V.
  • 31
  • 1
  • 1
  • 2
  • 1
    It may help to include the domain, if you are able, so that people answering can query the server directly. – Ladadadada Dec 05 '13 at 19:25
  • 8 years since the original post I have the same problem...I have a wildcard cert (*.myorg.com) installed on an internal (intranet) server. Chrome and Edge report this cert as invalid but it is valid. What was the final resolution to this? Would it still work now? – cymorg Dec 13 '21 at 15:37

2 Answers2

1

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
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • The intermediate certificates are fine, that's one the first suggestions I got from tech support. I investigated a bit more and apparently there's a bug in Google Chrome since it works just fine in the beta (32.0) and dev/Canary (33.0) – Rafael V. Dec 05 '13 at 22:01
  • Is there a specific order in the chained certificate ? – julienfr112 Jan 12 '14 at 12:46
1

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.

CervEd
  • 105
  • 3
Stuart
  • 101
  • 2
  • presumably your suggestion is to omit the `Subject` field? – CervEd Nov 19 '21 at 07:12
  • No you need the subject field, it is just that this no longer used for the site URL (in the CN= field) that these all need to be in the alternate name filed. – Stuart Nov 20 '21 at 09:18
  • So omit the `Subject: CN = domain` – CervEd Nov 20 '21 at 09:52
  • No it is also needed in the subject field for legacy reasons. Best to make the the main name for the site, so set this to example.com and then put example.com and www.example.com in the alternative name filed – Stuart Nov 21 '21 at 23:41
  • that's the problem. It seems if you have the example.com in the subject and *.example.com, example.com in the alternate, chrome won't accept the certificate for foo.example.com but will for example.com – CervEd Nov 22 '21 at 08:48