Basics: Name Constraints

Name restrictions are a part of the X.509 standard and in the RFC 5280 described. They are a tool that can be used within the qualified subordination can be used to control the validity range of a certification authority certificate in a fine-grained manner.

Excursus qualified subordination

The objective of qualified subordination is to restrict the extent to which a Certification Authority or a Certification Authority hierarchy is trusted.

Components of Qualified Subordination can be:

Component	Description
Path length restriction (Path Length Constraint)	This can be used to define how many hierarchy levels (i.e. subordinate Certification Authorities) may follow the Certification Authority in question.
Restrictions on extended key usage (Extended Key Usage Constraints)	This can be used to specify which extended key usages may be accepted in certificates issued by the certification authority.
Restrictions of the Issuance Policies	This allows you to specify for which certificate policies the Certification Authority may confirm their conformity in issued certificates.
Name restrictions (Name Constraints)	This can be used to define for which namespaces the certification authority may issue certificates.

Motivation for the mission

Don't forget: PKI is a distributed system. The root CA may belong to a different organization than the child CAs.

Motivators for using name restrictions may include:

As a PKI operator, you delegate certificate authority certificates to your customers and want to limit their scope of use to prevent misuse.
One operates a certification authority whose certificate issuance is delegated to third parties. Examples of this would be certificate requests made manually, those made via the Network Device Enrollment Service or those provided by mobile device management (MDM) systems.
One wants to limit the potential for damage if a certification authority is compromised.

A good example of the consistent applications of qualified subordination and, in particular, name restrictions is the Bavarian SSL-CA-2015-01whose CA certificate is publicly viewable.

Specification in RFC

Name restrictions are defined in the RFC 5280 specified. They can only be applied to subordinate certification authority certificates.

The defined restrictions can be specified in the form of a list of permitted and/or in the form of a list of prohibited namespaces for the Subject Distinguished Name and the Subject Alternative Names of issued certificates. If prohibited namespaces are defined, they take precedence over permitted namespaces.

The following types of restrictions are possible, among others:

Type	Description
directoryName	Restrictions of the Relative Distinguished Names (RDNs) in the Subject Distinguished Name.
rfc822Name	Restrictions on email addresses in the Subject Alternative Name.
uniformResourceIdentifier	Restrictions on URLs in the Subject Alternative Name.
dNSName	Restrictions of DNS names in the Subject Alternative Name.
iPAddress	Restrictions on IP addresses in the Subject Alternative Name.

As a minimum, the RFC requires that applications that check certificates understand at least constraints on the directoryName and recommends that at least the rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress are also understood.

Please note that the name restrictions cannot enforce the presence of one of the defined Subject or Subject Alternative Name part contents. If the defined part is not present in the certificate request, this is considered valid (partial restrictions are possible):

Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.
https://tools.ietf.org/html/rfc5280#section-4.2.1.10

To ensure that all participants speak as much of the same language as possible, standards are defined by the IETF in RFCs (Request for Comment). The relevant standard for certificate profiles in PKI is the RFC 5280 unambiguously requires that the "Name Constraints" certificate extension must be marked as critical.

Conforming CAs MUST mark this extension as critical
https://tools.ietf.org/html/rfc5280#section-4.2.1.10

Applications that check the certificate chain and do not know the "Name Constraints" certificate extension will therefore not be able to process it and thus will not be able to accept the issued certificates.

Compatibility note: Apple does not play with

For Mac OS, correct processing of name extensions has been with version 10.13.3 implemented. There are unconfirmed indicationsthat name restrictions could be supported by Apple iOS in the meantime.

As is often the case in the area of public key infrastructure, the saying here is once again: "It always depends on the implementation in the application".

And unfortunately there is the problem that all Apple products are not compliant to RFC 5280since they do not support name restrictions. Accordingly, they will reject certificates from correctly restricted certificate authorities (after all, this part is implemented in compliance with RFC).

Applications conforming to this profile MUST be able to process name constraints [...] the application MUST either process the constraint or reject the certificate.
https://tools.ietf.org/html/rfc5280#section-4.2.1.10

Since Apple also does not give browser and app makers the choice of using their own crypto programming libraries, either no Apple devices with name restrictions can be used or no name restrictions can be used with Apple devices.

The only remaining way out on the PKI side would be to violate the RFC and not mark the extension as critical for name restrictions.

The company previously mentioned as a positive example Bavarian SSL-CA-2015-01 by the way does exactly that and thus does not fully comply with RFC 5280, since the extension for name restrictions in the certificate authority certificate is just not marked as critical - the reason is obvious.

The same statement can be found from one of the inventors of Active Directory Certifcate Services, who also appeared in the IETF as a representative of Microsoft:

For customers this means if you must interoperate with Opera or Safari (yes even on iPad and iPhone) the use of a certificate with a "Critical" "Name Constraints extension" in it will result in the certificate chain looking invalid. [...] This issue can be addressed by not marking the extension Critical, when this is done the clients that understand Name Constraints will continue to honor the policies expressed in it and those that do not will simply ignore the extension. This is of course a trade-off of security in exchange for compatibility, with that said one with far more positive trade-offs than negative ones.
Least Privilege and Subordinate Certificate Authorities (Ryan Hurst)

Implementation in Microsoft PKI

The Microsoft Certification Authority will refuse to issue certificates that violate the name restrictions. However, this can be remedied with the flag CRLF_IGNORE_INVALID_POLICIES switch off (not recommended), or it could also be directly Issue certificates using the private key directly. Name restrictions thus do not (only) have the aim of Exhibition invalid certificates, but rather to prevent their (non-)use.Acceptance by those who are to check or use them.

The name restrictions are written to the certification authority certificate of the relevant certification authority (they are set by the respective higher-level instance).

The restrictions can either be included in the certificate request of the relevant Certification Authority (capolicy.inf), or the parent certification authority applies an appropriate configuration before issuing the certification authority certificate.

The definition in basic construct looks like this:

[NameConstraintsExtension]
Include = PermittedSubtrees
Exclude = ExcludedSubtrees
Critical = True

[PermittedSubtrees]
; Directives here

[ExcludedSubtrees.]
; directives here

The definition may also be written in the following alternate notation:

[Strings]
szOID_NAME_CONSTRAINTS = "2.5.29.30"
  
[Extensions]
Critical = %szOID_NAME_CONSTRAINTS%
%szOID_NAME_CONSTRAINTS% = "{text}"
_continue_ = "SubTree=Include&"
_continue_ = ; directives here, end each line with &.
_continue_ = "SubTree=Exclude&"
_continue_ = ; Directives here, end each line with &.

The following directives are possible:

Definition according to RFC 5280	Entry in capolicy.inf	Example
directoryName (Subject)	DirectoryName	DC=intra,DC=adcslabor,DC=de
dNSName (SAN)	DNS	intra.adcslabor.com .intra.adcslabor.com
rfc822Name (SAN) emailAddress (Subject)	Email	@adcslabor.com .adcslabor.com
iPAddress (SAN)	IPAddress	10.0.0.0, 255.0.0.0 172.16.0.0, 255.255.0.0 192.168.0.0, 255.255.255.0
(unspecified) userPrincipalName	UPN	intra.adcslabor.com .intra.adcslabor.com

The SAN type userPrincipalName is not specified in RFC 5280 because it is proprietary to the Microsoft ecosystem. It is therefore not guaranteed that other PKI implementations can interpret it correctly (or at all).

It is also possible to specify the "empty" keyword. This can be used to explicitly disallow certain Subject Alternative Name types. For the directoryName type this directive cannot be used. For the range of allowed namespaces the keyword has no effect.

Note on some incorrect documentation

Popular Documentations claim that it is necessary to put a dot in front of a defined DNS namespace to allow subdomains, for example. In fact, this is not required at all. See here the corresponding passage in the relevant RFC.

DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not.
https://tools.ietf.org/html/rfc5280

Effectively, the applicant or the certification authority can freely choose the "left" part of the DNS name, including subdomains.

However, it makes sense to put a dot in front of the domain name as this only allows the issuance of identities below the specified domain, but not for the domain itself.

Problem Subject Distinguished Name

If you set name constraints only for DNS names, you can still request any identity as a Subject Distinguished Name. The only way to restrict the Subject Distinguished Name is to define constraints of type "directoryName".

However, it is not possible with this for the commonName, which is only a part of the Subject Distinguished Name and from which in many cases the identity is formed, to set restrictions. Either one allows all values or none at all.

Thus, it is not possible to restrict the commonName to certain identities (e.g. only hosts below intra.adcslabor.de).

Reasonable exceptions

There are some certificate types that are necessary for certificate authority operation and therefore their Subject Distinguished Names should always be included in the list for allowed directoryNames:

Certificate type	Description
Certification Authority exchange	Generally issued by the certification authority. Contains the commonName of the certification authority with a "-Xchg" suffix and all other RDNs that also appear in the certification authority certificate. If the exception for this is missing, these certificates cannot be generated. As a result, failed certificate requests regularly end up in the database and pkiview.msc is not fully usable.
Certificate Registration Agent	Will be used for the Registration Authority Certificates of the Network Device Enrollment Service used. If the exception for this is missing, NDES cannot be used with this certification authority.
Online responder	Is used for the response signature certificates of the Onlineresponders used. If the exception for this is missing, no online responder can be used with this certification authority.

A solution for some (but not all) cases

So, in the following example, let's try to set name constraints for a certificate authority that is exclusively Web server certificates shall issue.

Suppose we want to restrict a certificate authority that only issues certificates for hostnames within the DNS domain intra.adcslabor.com should issue. We know that we cannot restrict the commonName in any meaningful way.

The entry of server names in the subject was not even intended when the X.509 standard was defined. Therefore, the RFC 2818 for HTTPS, the use of the Subject Alternative Name in the form of the dNSName attribute instead of the commonName in the Subject has also been in use since 2000.

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
https://tools.ietf.org/html/rfc2818

The RFC 5280 again specifies that in such a case the subject field may be empty:

Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the subjectAltName extension MUST be present. If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical.
https://tools.ietf.org/html/rfc5280

The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension.
[...]
If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical.
https://tools.ietf.org/html/rfc5280

For this use case, one could at least define a name restriction for a certification authority certificate that does not accept commonNames in the subject - which, with respect to RFC2818 (and thus only in the sense of Web server certificates) but would be perfectly acceptable.

Consequently, this only works if the certificate authority is used exclusively for web server certificates. The identities in the certificates can only be mapped in the Subject Alternative Name in the form of a dNSName (or an iPAddress, but this is not discussed here).

It is therefore essential to set a directory name constraint so that no invalid commonNames, but only the defined commonNames, can be used in the certificate request.

The goal can be realized, for example, by setting the constraint on the allowed namespaces to a predefined value, e.g. "CN=INVALID". This means that either only an empty Subject Distinguished Name or one of the defined values is possible. However, it is basically sufficient if one of the exceptions for the cases described above is present to achieve this goal.

A corresponding content in a minimal capolicy.inf would look like this:

[Version]
Signature= "$Windows NT$"

[Strings]
szOID_NAME_CONSTRAINTS = "2.5.29.30"

[Extensions]
Critical = %szOID_NAME_CONSTRAINTS%
%szOID_NAME_CONSTRAINTS% = "{text}"
_continue_ = "SubTree=Include&"
_continue_ = "DNS = .intra.adcslabor.com&"
_continue_ = "DIRECTORYNAME = CN=ADCS Lab Test Issuing CA 1-Xchg&"

[Certsrv_Server]
LoadDefaultTemplates=0

In addition, it is highly recommended, to restrict the extended key usages for the certification authority in such a waythat only the defined use cases are supported. Likewise, a Path length restriction very useful.

Function test

For the test, we have a certification authority certificate issued with the defined restrictions.

The tests were performed with the PSCertificateEnrollment PowerShell module is performed.

If we request a certificate for a DNS name within intra.adcslabor.com, the certificate request is approved.

If we request a certificate for a DNS name within an undefined DNS domain, the certificate request is rejected as expected.

If we request a certificate for a DNS name within intra.adcslabor.de, and an undefined commonName, the certificate request is rejected as expected.

Assessment for practicality

Name restrictions allow some influence on the certificate content. The advantage is that violations are also detected when a certificate is checked during certificate verification (...can - if implemented) and such certificates would then not be accepted.

However, the restrictions can only be implemented in an incomplete manner. For example, it is only possible to restrict certificate issuance to identities within certain DNS namespaces. However, it is not possible to restrict which identities are requested here.

Likewise, it should be remembered that the RFC only requires that constraints on the directoryName be understood. Thus, there is no guarantee that all participating applications will also understand the Other types understand

In general, of course, the whole construct is also very inflexible, since no changes are possible in retrospect without re-signing the certification authority certificate.

A more flexible alternative can be the TameMyCerts Policy Module be for the Certification Authority.

Conclusion

For some cases, name restrictions according to RFC 5280 are thus completely unsuitable. Even if there are no technical obstacles, they are only suitable to a limited extent for cases where the requester can bring the identity in the certificate request.