2

I'm trying to create a private CA and want it to only be able to issue certificates for my domain via name constraints.

However, even if I create the CA with restrictions on DNS names as well as directory names like this

New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My\ -Type Custom -KeyUsage CertSign,CRLSign -NotAfter (Get-Date).AddYears(100) -Subject "CN=My Root,DC=mydomain,DC=tld" -TextExtension @("2.5.29.19={critical}{text}ca=true&pathlength=0", "2.5.29.30={critical}{text}subtree=Include&DNS=mydomain.tld&DNS=.mydomain.tld&[email protected]&Email=.mydomain.tld&[email protected]&upn=.mydomain.tld&DirectoryName=DC=mydomain,DC=tld")

I can still generate TLS certificates for other domains that do not fail validation by not specifying a SAN field and appending DC components to the subject's distinguished name like this

New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My\ -Type SSLServerAuthentication -Signer Cert:\CurrentUser\My\<ca_cert_id> -Subject "cn=someotherdomain.com,dc=mydomain,dc=tld"

Is there a way to specify directory name constraints to prevent this from happening?

Improve this question

2 Answers 2

Reset to default
3

There are couple of issues.

  1. You should use specialized CA software instead on PowerShell scripts. Even for testing, because you cannot make fully functional tests in real-world scenarios.

  2. Since you haven't specified specified SAN extension in leaf certificate, then subject is used for name validation if client application agrees to. No modern browser will accept a certificate without SAN extension, thus your certificate will fail validation in these applications because of missing SAN extension (not related to name constraints). However non-browser applications (various types of HTTP/SSL Stream clients) are not required to follow CAB Forum baseline requirements and can fall back to Subject field.

  3. Only DirectoryName name type in name constraints apply to Subject field, because Subject field is in a form of DirectoryName. In your setup, anything under DC=mydomain,DC=tld X.500 subtree (to the left of the string) is permitted. Since leaf certificate falls under this permission, thus Subject is technically valid.

What you should do here is to define SAN extension in leaf certificate which will completely invalidate Subject field and restrict fallback to Subject field.

See RFC 5280 §4.2.1.10 for more details about name constraints.

And consider the response from @garethTheRed. You shall not apply any sort of constraints or restrictions on root certificate, they must be applied at lower levels. The purpose of root certificate is to provide trust anchor functionality.

Improve this answer
7
  • Firefox is modern and still accepts cert without SAN, and TTBOMK so does Safari.
    – dave_thompson_085
    Commented Mar 29, 2022 at 4:33
  • @dave_thompson_085 by default?
    – Crypt32
    Commented Mar 29, 2022 at 6:45
  • The whole point of me going out of my way to add name constraints to the CA is to limit damage in case a malicious actor gained access to the private key. Such a malicious actor would definitely issue certs without SAN if that allowed him to get around the DNS name constraints. The question is: how can I specify DirectoryName constraints to prevent the CN to point to any domain other than mine?
    – VelvetRebel
    Commented Mar 29, 2022 at 9:56
  • 1
    You can't do this with DirectoryName name type constraints. And if attacker gained access to CAs private key -- your CA is compromised with unfortunate consequences. And name constraints is your least problem here.
    – Crypt32
    Commented Mar 29, 2022 at 10:00
  • 1
    RFC 2818 states If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Therefore, if you just stick to DNS names in a SAN extension and forget the whole Common Name piece, it should work for all conforming relying parties. Assuming you're using the certs for HTTPS of course.
    – garethTheRed
    Commented Mar 29, 2022 at 11:56
0

You don't apply name constraints to the root CA certificate. It asigns name constraints to certificates it issues.

There's no guarantee or expectation that name constraints or other extensions in root CA certificates are honoured.

Improve this answer
7
  • Yes there is -- rfc5280 6.1.2 b and c. It is more common to add name constraints at an intermediate below the root, but it is possible on the root, especially if you want to issue EEs/leaves directly under the root (not allowed for a cabforum CA, and usually not a good idea for a private one, but possible).
    – dave_thompson_085
    Commented Mar 29, 2022 at 3:45
  • @dave-thompson-085 re "especially if you want to issue EEs/leaves directly under the root" can you please explain why name constraints are useful there?
    – Rodrigo Murillo
    Commented Mar 29, 2022 at 6:58
  • @dave_thompson_085 - the common assumption there is that all trust-anchors are certificates. If the relying party used the Subject Name and Public Key only, any additional information in the certificate would be lost. For example, the Java TrustAnchor class and RFC 5914 TustAnchorInfo.
    – garethTheRed
    Commented Mar 29, 2022 at 9:37
  • Why do I not apply constraints to the root? I have a domain and am creating a private CA: everything I would be issuing certificates for is going to live under this domain and there is no legitimate case in which my CA would be issuing certs for external domains. I do not want the cert to be used to spoof google.com or my bank for example.
    – VelvetRebel
    Commented Mar 29, 2022 at 9:51
  • In your use case, a DNS name constraint on the Root CA cert may well work as you would/should have some reasonable control of the relying parties and therefore should know if they're using certificates for their trust-anchors and if those relying parties take heed of all extensions in the Root CA cert.
    – garethTheRed
    Commented Mar 29, 2022 at 11:57

You must log in to answer this question.

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