13

I have the following "chain" of certificates on a test machine right now:

  • A self-signed CA cert, in my Keychain and trusted & trusted by Firefox.

  • A CA cert with with the following,

    X509v3 Name Constraints: critical
  Permitted:
    DNS:mydomain.net
    DNS:.mydomain.net

  • A non-CA cert with signed by the above.

The test webserver serves the latter two certs; the first is marked as "trusted" in Keychain in OS X, in Firefox itself, and on my Linux side, also in FF and by certutil.

On OS X, Firefox accepts the connection as secure; Chrome and Safari do not. It looks like Chrome & Safari just uses whatever the OS uses for crypto purposes, so here, OS X is the issue. Viewing the cert shows:

"This certificate cannot be used (unrecognized critical extension)"

Extension: Name Constraints (2.5.29.30)
 Critical: YES
     Data: <a sequence of octets>

I'm guessing because I'm seeing a sequence of octets, and not a nice decoded view (like I do with other extensions), that this is the extension causing the error.

I can't get it to work on Linux either under Chrome (works fine in FF, again); there, however, it doesn't seem to be able to find the root cert (whereas on OS X it can); I think this is because I don't understand how to accept my self-signed cert. (The Internet says certutil, and I've tried just about every combination of that to no avail.)

Improve this question

2 Answers 2

Reset to default
8

#No. Apple does not support this.

Apple's Secure Transport library does not support X.509's nameConstraints.

There is a bug in Chromium's bug database about this. And it's been closed as WontFix. Developer Ryan Sleevi had this to say on Aug 25, 2014 (archived here):

Chrome defers to the OS cryptographic stack for verification.

It's a well-known, long-standing issue that Apple does not implement name constraints. This applies to all applications that use OS X's SSL or certificate verification libraries (e.g. Safari, Curl, Python, etc)

#Related

Improve this answer
4
  • Thanks for this answer. I'd have spent all day troubleshooting this if I hadn't found your note. Good work on the archived external confirmation too.
    – jorfus
    Commented Oct 19, 2016 at 18:01
  • 2
    It looks like this may no longer be the case. I can't find any useful developer documentation (and I don't have a Mac to test on), but iOS change notes at support.apple.com/en-gb/HT208463 and macOS notes at support.apple.com/en-gb/HT208465 mention fixing "A certificate evaluation issue ... in the handling of name constraints". Can anyone confirm when this functionality was first added?
    – Joe Lee-Moyet
    Commented Aug 19, 2019 at 12:46
  • @JoeLee-Moyet: Good question! Dunno, I don't have an apple device handy to test. -- Apple's quote "Impact: A certificate may have name constraints applied incorrectly" certainly reads like name constraints ARE in fact supported.
    – StackzOfZtuff
    Commented Aug 19, 2019 at 13:35
  • There is now a public test suite available: nameconstraints.bettertls.com According to this, both Safari and Chrome on my Mac running macOS 10.15.4 support name constraints.
    – lxgr
    Commented May 13, 2020 at 20:17
12
+50

Yes, OS X / macOS supports this since 10.13.3.

According to the https://nameconstraints.bettertls.com archived tests, 10.13 failed some tests but 10.13.3 passes all in with both Safari and Chrome.

This fit's the timeline release notes for macOS 10.13.3 which lists the following fix1

Description: A certificate evaluation issue existed in the handling of name constraints. This issue was addressed with improved trust evaluation of certificates.

Firefox who uses it's own internal TLS passes since at least version 50.

This also matches lxgr's comment about it working on 10.15.4 comment and my test today on 10.14.6

1as pointed out by Joe Lee-Moyet in the comments

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .