Mac OS X - Accept self-signed multi domain SSL Certificate

Question

I've got a self-signed certificate for multiple domains (let's say my.foo.bar.com & yours.foo.bar.com) that I've imported using Keychain Access but Chrome will still not accept it, prompting me for verification at the beginning of each browsing session per domain.

The Certificate was generated using the x509v3 subject alternative name extension to validate multiple domains. If I navigate to the site before I import the certificate, I get a different warning message than after importing. Attached below is an image of the two errors (with the top being the error before imported)

enter image description here

Is there any way to accept a self-signed multi-domain certificate? I only get warnings in Chrome, btw. FF and Safari work great (except those browsers suck ;) )

UPDATE: I tried generating the cert both with the openssl cli and the xca GUI

How exactly did you generate your cert? Why subject key identifiers? Did you mean subject alternative names? — Bruno
Just updated my answer. Yes to subject alternative names. I tried generating both with the openssl CLI tools and xca (sourceforge.net/projects/xca) — David Welch
Have you made sure your SANs are of DNS type? (xca gives a choice between URI, DNS and IP at least, as far as I remember) — Bruno
"(with the top being the error before imported)" That's probably the other way around. — Bruno
Nope, top is definitely before import. Yeah, SANs are listed as DNS. Ideally, I'd like to specify the SANs as , *., etc. to support unlimited subdomains. All of this is just for a testing dev box where we use multiple nested subdomains (which I hate, but what can you do) — David Welch

Bruno Bruno · Accepted Answer · 2013-04-09T23:20:33

The problem is that you're trying to use too broad a wildcard (* or *.com).

The specifications (RFC 6125 and RFC 2818 Section 3.1) talk about "left-most" labels, which implies there should be more than one label:

 1.  The client SHOULD NOT attempt to match a presented identifier in
     which the wildcard character comprises a label other than the
     left-most label (e.g., do not match bar.*.example.net).

 2.  If the wildcard character is the only character of the left-most
     label in the presented identifier, the client SHOULD NOT compare
     against anything but the left-most label of the reference
     identifier (e.g., *.example.com would match foo.example.com but
     not bar.foo.example.com or example.com).

I'm not sure whether there's a specification to say how many minimum labels there should be, but the Chromium code indicates that there must be at least 2 dots:

We required at least 3 components (i.e. 2 dots) as a basic protection against too-broad wild-carding.

This is indeed to prevent too broad cases like *.com. This may seem inconvenient, but CAs make mistakes once in a while, and having a measure to prevent a potential rogue cert issued to *.com to work isn't necessarily a bad thing. If I remember correctly, some implementations go further than this and have a list domains that would be too broad for second-level domains too (e.g. .co.uk).

Regarding your second example: "CN:bar.com, SANs: DNS:my.foo.bar.com, DNS:yours.foo.bar.com". This certificate should be valid for my.foo.bar.com and yours.foo.bar.com but not bar.com. The CN is only a fallback solution when no SANs are present. If there are any SANs, the CN should be ignored (although some implementations will be more tolerant).

Mac OS X - Accept self-signed multi domain SSL Certificate

1 Answers