https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs https://wiki.mozilla.org/CA:Problematic_Practices#Allowi

https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_e... And from https://wiki.mozilla.org/CA:SubordinateCA_checklist https://wiki.mozilla.org/CA:SubordinateCA_checklist "Third-party private (or enterprise) subordinate CAs: This is the case where a commercial CA has enterprise customers who want to operate their own CAs for internal purposes, e.g., to issue SSL server certificates to systems running intranet applications, to issue individual SSL client certificates for employees or contractors for use in authenticating to such applications, to issue SSL certificates for pre-approved domains that are owned/controlled by the customer, and so on. These sub-CAs are not functioning as public CAs. For these sub-CAs we need assurance that they are not going to start functioning as public CAs. Currently the only assurances available for this case it to ensure that these third parties are required to follow practices that satisfy the Mozilla CA Certificate Policy, and that these third parties are under an acceptable audit regime. In Bug #394919 NSS is being updated to apply dNSName constraints to the CN, in addition to the SANs. We plan to update our policy to require CAs to constrain third-party private (or enterprise) subordinate CAs so they can only issue certificates within a specified domain. See section 4.2.1.10 of RFC 5280."