X.509 Name Constraints certificate extension – all you should know

Hello S-1-1-0, PowerShell CryptoGuy (aka @Crypt32) is here again. Today I want to discuss about X.509 Name Constraints certificate extension. It is not widely used, but sometimes it is necessary. As extension name depicts, it is used to provide constraints or restrictions to certificate subject and subject alternative names (SAN) extension.

Brief Description

Name Constraints extension is defined and described in RFC 5280 §4.2.1.10. Extension presence in an end-entity certificate does not have any effect and is applied only to CA certificates that issue certificates to end entities. Once defined, the extension applies restrictions on any certificates that appear below that CA in the tree. Name Constraints may appear further in the certification path to set more restrictive constraints. It is not possible to set less restrictive constraints at lower levels. This prevents low-level (in the certification path meaning) CAs to violate restrictions applied at higher levels.

PKI Hierarchy

Figure 1 - sample certificate chain

Here we see a 3-tier PKI hierarchy with applied Name Constraints extension at 2nd level (below root). This is indicated by a yellow triangle. Name Constraints restrictions are applied to all directly and indirectly issued certificates. CA-2 doesn’t define Name Constraints extension in its own certificate, but restrictions still apply to certificates issued by CA-2 indirectly.

Common Scenarios

Although Name Constraints extension is not widely used, it may be mandatory in certain PKI deployment scenarios. Generally, these scenarios include (but not limited to) CA deployment in a partially trusted environments. The following sections

Cross-certification between two or more parties

This scenario assumes that two (or more) organizations run their own business and have tight communications between each other. For example, employees of two companies exchange secure emails, digitally signed documents, encrypted files and so on. Each company run its own PKI with separate CAs. By default, Company1 (say, Contoso) won’t trust certificates issued by Company2 (say, Adatum), because their PKIs are private and not generally trusted. Opposite is true: Adatum won’t trust certificates issued by Contoso.

To establish a trust, companies may issue cross-certificates to each other, so Contoso will trust certificates issued by Adatum and vice versa. However, each party must protect themselves from a possible certificate issuance violations. For example, Contoso don’t want Adatum to issue certificates for Contoso namespace, because it will lead to a serious security breach. And Adatum don’t want Contoso to issue certificates for Adatum namespace. Otherwise, Adatum will be able to impersonate users from Contoso. Thus, companies agree on terms at which certificates are trusted. One term is that Contoso will trust Adatum certificates issued only to Adatum namespace. No other namespaces are permitted. As always, opposite is true. This restriction is achieved by applying Name Constraints extension in cross-certificates.

CA bridge deployment

CA bridge is a larger version of cross-certification. It is intended for the same purposes and just for larger scales. Individual cross-certification is effective when there are very few parties (no more than 4-5). Once the party count is increased, the number of totally issued cross-certificates (to provide a fully connected network of trust) grows in the following proportion: and quickly becomes enormous. For example, for 6 parties, it will require 15 certificates, for 7 parties it will require 21 cross-certificate. To solve this problem a special Bridge CA is implemented:

Bridge CA

Figure 2 - sample Bridge CA

Bridge CA is a standard CA which issues cross-certificates to each party and each party issue certificates to Bridge CA. This will provide fully connected network of trust, so each party will trust other bridge party CAs and will require only cross-certificates.

PKI deployment in decentralized managed environments

This often occurs when the company runs multiple Active Directory forests (during another company acquisition, for example). In this case, head company deploys single root CA and each forest run subordinate CAs and are managed by respective forest administrators. Subordinate CA certificates will include Name Constraints extension to protect each forest from certificate misissuance by other forests.

Name Constraints components and syntax

In Internet PKI profile, Name Constraints extension is defined in . It consist of two optional (however, at least one component must present) components:

  • Permitted Subtree
  • Excluded Subtree

Permitted subtree contains definitions for allowed namespaces, while Excluded subtree contains definitions for explicitly disallowed namespaces. Each subtree’s entry is provided in an Alternative Name form (like Subject Alternative Names extension). The most common alternative name forms are:

  • Directory Name (X.500 distinguished name)
  • DNS Name
  • IP Address (IPv4 and IPv6)
  • RFC 822 name (email)
  • User Principal Name (UPN)

and others. Below is an example syntax for INF file to use in Microsoft certreq.exe utility:

[NameConstraintsExtension]
Include = PermittedSubtree ; permitted subtree
Exclude = ExcludedSubtree ; excluded subtree
Critical = True

[PermittedSubtree]
DirectoryName = "DC=contoso,DC=com" ; allows any name blow this root
DNS = contoso.com ; allows *.contoso.com, for example, www.contoso.com
DNS = .contoso.com ; allows subdomains: www.sub.contoso.com
Email = @contoso.com ; allows someone@contoso.com
Email = .contoso.com ; allows someone@sub.contoso.com
IPAddress = 192.168.0.0, 255.255.255.0 ; format: {IP network address},{Subnet Mask}

[ExcludedSubtree]
DirectoryName = "DC=Branch,DC=contoso,DC=com" ; explicitly disallows DC=Branch,DC=contoso,DC=com entire subtree
DNS = branch.contoso.com ; disallows branch.contoso.com
DNS = .branch.contoso.com ; disallows subdomains: www.sub.branch.contoso.com
UPN = empty ; disallows any name of User Principal Name form
Email = @branch.contoso.com ; disallows someone@branch.contoso.com
Email = .branch.contoso.com ; disallows someone@sub.branch.contoso.com

The syntax should be self-explanatory. We define one or both subtrees (permitted and/or excluded) and provide name constraints in required name form.

Processing rules

Name constraints processing rules are not easy to understand, but they are similar to NTFS permissions in certain aspects. To make it easier to understand, I will provide examples to show how name is validated.

Certificate chaining engine (CCE) performs name validation after constructing certificate chain (or certification path) starting from root CA certificate down to certificate being processed. If we take a loot at Figure 1, CCE will take each name in the certificate (including Subject field and SAN extension) and process it in the following direction for the certificate issued by Subordinate Policy and Issuing CA-1:

1 - Root CA
    2 - Subordinate Policy and Issuing CA-1
        3 - Subordinate Policy and Issuing CA-2

If particular name in leaf certificate is excluded at some point, this name will be invalid for that leaf certificate. In short, CCE will compare each name with Name Constraints extension and passes down only valid name. If the name is excluded, CCE will take another name and starts over. Names reached leaf certificate (which weren’t excluded and eliminated) are the only valid names for the certificate being processed. I hope, this general behavior is clear for you.

The following sections will describe exact processing rules at each CA level depending on Name Constraints configuration. As said above, Name Constraints extension may have the following configurations:

  • Only Permitted Subtree is defined
  • Only Excluded Subtree is defined
  • Permitted and Excluded Subtrees are defined

Let’s start with general subtree processing rules. Configuration when no subtrees are defines is not valid.

All examples in this section, assume that CA certificate has Name Constraints with sections according to INF configuration provided above.

Only Permitted Subtree is defined

If only Permitted Subtree is presented, then only names that matches to name patterns defined in Permitted Subtree section. This means that particular name must match at least one pattern in the matching name form. For example, if certificate name is in the DnsName form, it must match to any DnsName form specified in the configuration. Otherwise the name is excluded. The following examples assume that there is no Excluded Subtree section in the CA certificate.

Example 1: validating DnsName = www.contoso.com. This name has one matching entry in permitted subtree: DNS = contoso.com. As the result, DnsName = www.contoso.com name is allowed.

Example 2: validating Email = admin@sub.contoso.com. This name has one matching entry in permitted subtree: Email = .contoso.com. As the result, Email = admin@sub.contoso.com name is allowed.

Example 3: validating DnsName = 192.168.0.5. This name has one matching entry in permitted subtree: IPAddress = 192.168.0.0, 255.255.255.0. Although, name pattern matches – IP address falls to allowed subnet, name forms are not matching. As the result, DnsName = 192.168.0.5 name is excluded and not allowed.

Example 4: validating UPN = admin@sub.contoso.com. This name has no matching in permitted subtree. However, Name Constraints configuration doesn’t have UPN name form definitions.

As per RFC 5280 §4.2.1.10(g).(1):

Restrictions apply to the subject distinguished name and apply to subject alternative names. Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.

and §6.1.4:

If permittedSubtrees does not include a particular name type, the permitted_subtrees state variable is unchanged for that name type.

This means that if particular name form is not defined, then all names of that undefined form are allowed! Remember this!

Only Excluded Subtree is defined

If Name Constraints extension contains only Excluded Subtree, it works in blacklisting mode. If certificate name matches at least one entry in excluded subtree, the name is excluded and is invalidated. In all other cases the name is valid.

Example 1: validating DnsName = www.sub.branch.contoso.com. This name has one matching entry in excluded subtree: DNS = .branch.contoso.com. As the result, DnsName = www.sub.branch.contoso.com name is excluded and invalidated.

Example 2: validating Email = admin@sub.contoso.com. This name has no matching entry in excluded subtree. As the result, Email = admin@sub.contoso.com name is valid.

Example 3: validating IPAddress = 192.168.0.0, 255.255.255.0. There are no name forms of IPAddress in excluded subtree. This means that IPAddress = 192.168.0.0, 255.255.255.0 is valid.

Example 4: validating UPN = admin@contoso.com. There is an empty entry of UPN form. Empty sequence is a wildcard and literally disallows any namespace of that name form. In a given example, no UPNs are allowed in the certificate.

Permitted and Excluded Subtrees are defined

When both subtrees are defined, their processing rules are the same as described above with the following additional rule:

  • Permitted Subtree is processed first. If particular name is valid for permitted subtree, the name is processed by excluded subtree. Otherwise, the name is invalid.
  • Excluded Subtree is processed second. If particular name is valid for excluded subtree, the name is valid. Otherwise, the name is excluded and is invalidated.

Empty entries

As I already mentioned, empty entries imply wildcard entries. However, you should understand the difference in presence of empty entry in permitted and excluded subtrees.

  • When empty entry appears in permitted subtree the meaning is the same as name type definition absence in permitted subtree. This means that if you do not want to provide restrictions on particular name type, do not put it at all, otherwise it will take space in the certificate.
  • When empty entry appears in excluded subtree, the meaning is different. It explicitly disallows any namespaces of that type, while absence of particular type in excluded subtree means no restrictions on that type.

Diagram

the following diagram illustrates processing rules at each CA level:

Processing rules

Figure 3 - processing rules diagram

The diagram is not that beautiful as it could be, but it is correct. If someone or you have better diagram skills and can spend time to rewrite it – you are welcome!

Name Constraints extension support

As of now, Windows CryptoAPI and OpenSSL fully support Name Constraints certificate extension. However, neither of Apple products: Mac OS X, nor iOS does support this extension. Since, Name Constraints is always marked critical, Apple products will reject any certificate that contains Name Constraints extension in any certificate in the certificate chain.

Critical extensions are extensions that are mandatory for processing. If client software (i.e. certificate chaining engine) does not recognize critical extension, or extension value is unclear, the certificate must be rejected. In a given case, when Name Constraints extension is presented and no subtree is defined, client MUST reject the certificate, because critical extension is malformed.

HTH.

Comments:

Jordan
Jordan 15.11.2016 10:52 (GMT+2)

Hello Vadims,

Thanks for this interesting post. I have a question regarding processing of name forms within the subject name. Is the common name tested against DNS/IP addresses entries of name constraint subtrees or are those name forms only tested against corresponding SAN entries?

Second question, with your pkix library, how would you create an empty name form (like "UPN = empty")? Simply passing a blank string as the second argument of X509AlternativeName?

Thanks,

Vadims Podāns
Vadims Podāns 15.11.2016 19:13 (GMT+2)

Your question is very good. Indeed. The quick answer is No, IPAddress/DNS name forms are not tested against subject field. However, DirectoryName name form is tested against Subject field and against DirectoryName entries in SAN extension. There is one exception for RFC822 name. If Name Constraints define restrictions on RFC822 name form (Email), they apply to both, RFC822 name value in SAN extension (if presented) and to E(Email) RDN attribute in Subject field if SAN extension is absent in the certificate.

Another case includes IPAddress. As per RFC5280, empty entry of type of IPAddress in NameConstraints extension is not valid at all. It must be 8 (for IPv4) or 32 bytes (for IPv6) long value.  However, Microsoft implementation does support empty sequence in IPAddress name form.

As of second question. PKIX.NET library -- it doesn't fully support empty entries for particular name forms yet. I made modifications to allow extended values for IPAddress name form (for example) to support IP address and netmask (which are required in Name Constraints, but not allowed in SAN extension) altogether. Your point is valid and I would ask you to open a bug/feature request on GitHub. I think, my general X509AlternativeName class should allow empty entries for particular name type and empty names should be accepted by an X509NameConstraintsExtension class, but not by X509AlternativeSubjectNamesExtension and X509AlternativeIssuerNamesExtension classes. They should provide additional logic to check for empty sequences and disallow/ignore them.

Jordan
Jordan 16.11.2016 15:34 (GMT+2)

Hi and thank you for the reply.

Feature request posted on Github. I have no short term plan to use that feature myself so this would be for completeness I guess.

As for your first answer, this is too bad :/ This means that a classic TLS server authentication certificate putting a server's domain name in the common name but having no SAN extension at all (which is accepted by browsers of course) cannot be constrained by any name constraint extensions. And using a directory name constraint is of no use in that case since we do not care about the complete DN here but just the CN.

Vadims Podāns
Vadims Podāns 16.11.2016 20:33 (GMT+2)

> This means that a classic TLS server authentication certificate putting a server's domain name in the common name but having no SAN extension at all (which is accepted by browsers of course) cannot be constrained by any name constraint extensions

I consider your scenario is an example of technology misuse these days.

Many years back (in 1988 when X.509 profile was standartized) there was a big hope that everything in the world could be expressed in a X.500 distinguished name form and will be a part of the huge world-size DAP directory. That directory would define everything in the world: people (real people) organizations and even job positions in each organization. For example, root node is "." (dot) and many namespaces uner root that would define countries, each country will define child namespaces for states/cities, organizations registered in particular country and so on. For that purposes X.509 profile decided to use X.500 distinguished name form in Subject and Issuer fields. However, that idea failed and digital world moved from complex DAP to more flexible DNS. In those days, there were no certificate extensions, so Internet consorciums decided to change X.509 subject field use from original to another: describe and define other name forms in X.500 terms. As the result, real LDAP path is ignored. Valid RDN attributes are used to embed non-X.500 name forms. That is, to identify an end entity, CN attribute is used, E attribute is used to identify mail recipient/sender and so on. It was an ad-hoc solution until X.509 Version 3 profile was released.

X.509 V3 profile addressed all these issues by adding Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) left Subject and Issuer fields for compatibility purposes with previous profile versions (V1 and V2). X.509 V3 profile discourages Subject field usage unless it is a part of real DAP directory. If the entity is identified by a non-DAP path (i.e. DNS form), its identity MUST be defined in the SAN extension. These days, CAs still provide Subject field with fictional information for compatibility purposes. Another reason is that they used to do so many years ago. However, I can't imagine these days a crypto software that can't interpret X.509 V3 certificates.

To summarize all above, I want to say that embedding non-X.500 name forms in Subject field without putting them into SAN extension is technology misuse and against X.509 profile recommendations. This is why in X.509, DNS name constraints do not affect Subject field at all. That is, if you attempt to use the technology in a way it is not supposed to be used -- consequences might be unpredictable. I hope you understand the whole point.

Uwe-Jens
Uwe-Jens 20.02.2017 10:09 (GMT+2)

Hello Vadims,

I find your discussion very interesting and now I have the following question.

I have understood that a certificate with a dns name (e.g.: "abcd.efgh.ijkl") only in the Subject Name field is accepted as TLS server certificates on principle even if this is a misuse as you have explained. Could you please tell me what must be specified as Name Constraints in the respective CA certificate so that TLS server certificates issued under this CA for the domain "efgh.ijkl" will be rejected?

Thanks in advance.

Vadims Podāns
Vadims Podāns 23.02.2017 12:13 (GMT+2)

Just add "efgh.ijkl" as a DNS name in ExcludedSubtree section. Like I said, CN attribute in certificate's subject is equivalent to DNS name entry in SAN (in context of SSL, or course).

Captcha