3 ms·

No, although the root itself could be scoped that way with an X.509 name constraint. But if you add the root then I believe there's no browser policy to otherwi

by schoen 7y ago

No, although the root itself could be scoped that way with an X.509 name constraint. But if you add the root then I believe there's no browser policy to otherwise limit the names for which it can be trusted.

acdha 7y ago
On a tangent, do you know off-hand what browser support for name constraints is like? The last time I looked was a few years ago and at the time it wasn't well supported but if that's improved it'd be a good step for intermediate certs.
- jitbug 7y ago
  It must have been many many years ago, more than 10 at least. Any way to avoid or bypass name or path constraints would be considered a huge and monumental vulnerability today.
  - acdha 7y ago
    > It must have been many many years ago, more than 10 at least. You would be unduly optimistic — for example, Apple did not support them at least as recently as 2015 (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=407093#c2 https://bugs.chromium.org/p/chromium/issues/detail?id=407093...) and 10 years ago OpenSSL hadn't even shipped support upstream, plus however long it took your distribution to ship a major version upgrade to 1.0. I was hoping someone might have a pointer to current information on that topic since I believe Apple did finally fix Secure Transport but not when.
    - gnyman 7y ago
      I am afraid I don't have better information on when but some anecdotal information about the state of it. I have done some limited testing and research for our own internal Root CA I got the impression it works nowadays. I have not gotten as far as testing it in production but based on testing Safari and Chrome in https://nameconstraints.bettertls.com/ https://nameconstraints.bettertls.com/ and creating our own name constrained cert and testing it with both OS X Curl and Linux Curl (OpenSSL) I am still of the impression it works. Most other people seem to be sure that it does not though (for example in this discussion and here https://security.stackexchange.com/questions/95600/are-x-509-nameconstraints-on-certificates-supported-on-os-x https://security.stackexchange.com/questions/95600/are-x-509...) so I am not sure if I missed something or if people are just not up to date.
- wiml 7y ago
  The last time I looked into it, a few years ago, everyone except Apple had some basic amount of support. (That is, openssl, firefox, windows, and android — that's all I looked into.) I set up my private CA with name constraints, but I had to mark them noncritical if I wanted iDevices to be able to use the CA at all. But the other systems did at least appear to honor the constraints. I've asked Apple security folks about this a few times, but they just look uncomfortable and change the topic.
mdhardeman 7y ago
Actually true root certs when evaluated by the browsers will have their name constrains within the root certificate themselves ignored. Modern browsers do respect name constraints of intermediate issuing certificates.
- schoen 7y ago
  Thanks for the correction!

by schoen 7y ago

acdha 7y ago

On a tangent, do you know off-hand what browser support for name constraints is like? The last time I looked was a few years ago and at the time it wasn't well supported but if that's improved it'd be a good step for intermediate certs.

jitbug 7y ago
It must have been many many years ago, more than 10 at least. Any way to avoid or bypass name or path constraints would be considered a huge and monumental vulnerability today.
- acdha 7y ago
  > It must have been many many years ago, more than 10 at least. You would be unduly optimistic — for example, Apple did not support them at least as recently as 2015 (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=407093#c2 https://bugs.chromium.org/p/chromium/issues/detail?id=407093...) and 10 years ago OpenSSL hadn't even shipped support upstream, plus however long it took your distribution to ship a major version upgrade to 1.0. I was hoping someone might have a pointer to current information on that topic since I believe Apple did finally fix Secure Transport but not when.
  - gnyman 7y ago
    I am afraid I don't have better information on when but some anecdotal information about the state of it. I have done some limited testing and research for our own internal Root CA I got the impression it works nowadays. I have not gotten as far as testing it in production but based on testing Safari and Chrome in https://nameconstraints.bettertls.com/ https://nameconstraints.bettertls.com/ and creating our own name constrained cert and testing it with both OS X Curl and Linux Curl (OpenSSL) I am still of the impression it works. Most other people seem to be sure that it does not though (for example in this discussion and here https://security.stackexchange.com/questions/95600/are-x-509-nameconstraints-on-certificates-supported-on-os-x https://security.stackexchange.com/questions/95600/are-x-509...) so I am not sure if I missed something or if people are just not up to date.
wiml 7y ago
The last time I looked into it, a few years ago, everyone except Apple had some basic amount of support. (That is, openssl, firefox, windows, and android — that's all I looked into.) I set up my private CA with name constraints, but I had to mark them noncritical if I wanted iDevices to be able to use the CA at all. But the other systems did at least appear to honor the constraints. I've asked Apple security folks about this a few times, but they just look uncomfortable and change the topic.

mdhardeman 7y ago

Actually true root certs when evaluated by the browsers will have their name constrains within the root certificate themselves ignored. Modern browsers do respect name constraints of intermediate issuing certificates.

schoen 7y ago
Thanks for the correction!