[cabfpub] Name constrained certificate examples
Erwann Abalea
erwann.abalea at keynectis.com
Wed Jul 17 10:52:17 MST 2013
Bonjour,
Reading the X.509 standard (8.4.2.2 and Annex G):
* SSL1.cer is invalid because it has a SAN/dnsName containing
"anything.example.com" and its issuer CA has a NameConstraints only
allows dnsNames ending in "onlythis.com"; could you produce
certificates with matching names ("google.com"/"onlythis.com")?
* SSL2.cer is invalid for the same reason.
* SSL3.cer is valid ("C=US, ST=MA, L=Boston, O=Example LLC, O=Google,
CN=*.google.com" is a subordinate of "C=US, ST=MA, L=Boston,
O=Example LLC", which is the only permitted directoryName form, and
the EE cert doesn't contain a SAN extension).
I tried to find equivalent tests in PKITS, with no luck (the closer I
get is with a NC permitting a DN and an rfc822Name, and the EE has its
email in the SAN, not in the subject).
Testing with real browsers gives:
* FF22.0, SSL1.cer, SSL2.cer, SSL3.cer: NOK
L'autorité de certification pour ce certificat n'est pas autorisé à
délivrer un certificat avec ce nom.
(Code d'erreur : sec_error_cert_not_in_name_space)
* IE8/XPSP3, SSL1.cer, SSL2.cer, SSL3.cer: NOK
Le certificat de sécurité présenté par ce site Web a été émis pour
une autre adresse de site Web.
* I guess that Chrome and Safari will produce the same result on that
platform.
* Opera12.15/XPSP3, SSL1.cer, SSL2.cer: NOK
Connexion sécurisée: erreur fatale (47)
* Opera12.15/XPSP3, SSL3.cer: OK (owner is shown as "*.google.com,
Example LLC, Google")
* OpenSSL-based clients, SSL1.cer, SSL2.cer: NOK
Verify return code: 47 (permitted subtree violation)
* OpenSSL-based clients, SSL3.cer: OK
It seems FF and CAPI (XPSP3) consider that the CN is to be validated as
a dnsName and not part of the directoryName (whence, it's validated
against NC.PermittedSubTrees.dnsName instead of
NC.PermittedSubTrees.directoryName). This behaviour isn't mentioned in
RFC5280 either, but it's logical (legacy use of email addresses in the
subjectName is also mentioned in RFC5280, and the same kind of treatment
regarding NC extension is proposed). However, I don't know if that
behaviour is the result of heuristics (does the CN look like a FQDN?),
and how all this will work with internationalized domain names. There's
room for failures.
Opera uses OpenSSL, clearly, and they both follow X.509 to the letter.
I don't have anything more recent than XPSP3 as a VM, sorry.
--
Erwann ABALEA
Le 17/07/2013 17:09, Ben Lightowler a écrit :
>
> Hi Erwann,
>
> Steve asked me to put together some example certificates based on your
> concerns surrounding Name Constraints please find a zip attached with
> a Root and Issuing CA, as well as three SSL certificate created to
> your specifications in the examples you gave earlier.
>
> Hope this helps,
>
> *Ben Lightowler*
>
> Sales Engineer**
>
> **
>
> *GlobalSign*
>
> +44 (0) 1622 766766
>
> www.globalsign.co.uk <http://www.globalsign.co.uk/> |
> www.globalsign.eu <http://www.globalsign.eu/>
>
> Description: Description: secured-by-globalsign.gif
>
> **
>
> Springfield House, Sandling Road, Maidstone, Kent, ME14 2LP, UK.
>
> Tel: +44 1622 766766 Fax: +44 1622 662255
>
> Description: Description: oneclick-2
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130717/f2c7556e/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3627 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130717/f2c7556e/attachment-0002.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 25835 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130717/f2c7556e/attachment-0003.gif
More information about the Public
mailing list