12

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.)

Thanatos
  • 1,016
  • 2
  • 10
  • 16

2 Answers2

10

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

Gabriel
  • 153
  • 1
  • 4
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

Community
  • 1
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • 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 Oct 19 '16 at 18:01
  • 1
    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 https://support.apple.com/en-gb/HT208463 and macOS notes at https://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 Aug 19 '19 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 Aug 19 '19 at 13:35
  • There is now a public test suite available: https://nameconstraints.bettertls.com/ According to this, both Safari and Chrome on my Mac running macOS 10.15.4 support name constraints. – lxgr May 13 '20 at 20:17