RFC compliance

Certificate Authority Service uses the ZLint tool to ensure that X.509 certificates are valid as per RFC 5280 rules. However, CA Service does not enforce all RFC 5280 requirements and it is possible for a CA created using CA Service to issue a non-compliant certificate.

CA Service enforces the following RFC 5280 requirements.

RFC 5280 section	Lint clause
4.1.1.2	The signatureAlgorithm in Certificate MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (Section 4.1.2.3).
4.1.2.1	When extensions are used, as expected in this profile, version MUST be 3 (value is 2).
4.1.2.2	The serial number MUST be a positive integer assigned by the CA to each certificate.
4.1.2.2	Conforming CAs MUST NOT use serialNumber values longer than 20 octets.
4.1.2.4	The issuer field MUST contain a non-empty distinguished name (DN).
4.1.2.5	CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime
4.1.2.5.1	UTCTime values MUST be expressed in Greenwich Mean Time (Zulu)
4.1.2.5.1	UTCTime values MUST include seconds
4.1.2.5.2	GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu)
4.1.2.5.2	GeneralizedTime MUST include seconds
4.1.2.5.2	GeneralizedTime values MUST NOT include fractional seconds
4.1.2.6	If the subject is a CA (e.g., the basic constraints extension, as discussed in Section 4.2.1.9, is present and the value of cA is TRUE), then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field (Section 4.1.2.4) in all certificates issued by the subject CA.
4.1.2.8	Unique identifier fields MUST only appear if the version is 2 or 3
4.1.2.8	CAs conforming to this profile MUST NOT generate certificates with unique identifiers.
4.1.2.9	Extensions field MUST only appear if the version is 3
4.2	A certificate MUST NOT include more than one instance of a particular extension.
4.2	If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension
4.2.1.1	The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction.
4.2.1.1	Conforming CAs MUST mark authorityKeyIdentifier extension as non-critical.
4.2.1.2	To facilitate certification path construction, authorityKeyIdentifier MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension (Section 4.2.1.9) where the value of cA is TRUE.
4.2.1.2	Conforming CAs MUST mark subject key identifier extension as non-critical.
4.2.1.3	If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section 4.2.1.9) MUST also be asserted.
4.2.1.3	When the keyUsage extension appears in a certificate, at least one of the bits MUST be set to 1.
4.2.1.4	A certificate policy OID MUST NOT appear more than once in a certificate policies extension.
4.2.1.4	When qualifiers are used with the special policy anyPolicy, they MUST be limited to the qualifiers identified in this section.
4.2.1.5	Policies MUST NOT be mapped either to or from the special value anyPolicy
4.2.1.6	Whenever such identities (anything in a SAN) are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used;
4.2.1.6	If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical.
4.2.1.6	When the subjectAltName extension contains an Internet mail address, the address MUST be stored in the rfc822Name.
4.2.1.6	For IP version 4, as specified in [RFC 791], the octet string MUST contain exactly four octets. For IP version 6, as specified in [RFC 2460], the octet string MUST contain exactly sixteen octets.
4.2.1.6	When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String).
4.2.1.6	SANs: The dNSName MUST be in the "preferred name syntax"
4.2.1.6	subjectAltName extensions with a dNSName of " " MUST NOT be used
4.2.1.6	the use of the DNS representation for Internet mail addresses (subscriber.example.com instead of [e-mail]) MUST NOT be used
4.2.1.6	When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String).
4.2.1.6	SAN URIs: The name MUST NOT be a relative URI, and it MUST follow the URI syntax and encoding rules specified in [RFC 3986].
4.2.1.6	SAN URIs: The name MUST include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part.
4.2.1.6	SAN URIs that include an authority ([RFC 3986], Section 3.2) MUST include a fully qualified domain name or IP address as the host.
4.2.1.6	If the subjectAltName extension is present, the sequence MUST contain at least one entry.
4.2.1.6	conforming CAs MUST NOT issue certificates with subjectAltNames containing empty GeneralName fields.
4.2.1.7	Issuer alternative name MUST be encoded as in 4.2.1.6
4.2.1.8	Subject Directory Attributes: Conforming CAs MUST mark this extension as non-critical.
4.2.1.9	Where it appears, the pathLenConstraint field MUST be greater than or equal to zero.
4.2.1.9	Conforming CAs MUST include this extension in all CA certificates that contain public keys used to validate digital signatures on certificates and MUST mark the extension as critical in such certificates.
4.2.1.9	CAs MUST NOT include the pathLenConstraint field unless the cA boolean is asserted and the key usage extension asserts the keyCertSign bit.
4.2.1.10	The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located.
4.2.1.10	Name constraints: conforming CAs MUST mark this extension as critical
4.2.1.10	Conforming CAs MUST NOT issue certificates where name constraints is an empty sequence. That is, either the permittedSubtrees field or the excludedSubtrees MUST be present.
4.2.1.10	Within this profile, the minimum and maximum fields are not used with any name forms, thus, the minimum MUST be zero, and maximum MUST be absent.
4.2.1.10	The syntax of iPAddress MUST be as described in Section 4.2.1.6 with the following additions specifically for name constraints: For IPv4 addresses, the iPAddress field of GeneralName MUST contain eight (8) octets, encoded in the style of RFC 4632 (CIDR) to represent an address range [RFC 4632]. For IPv6 addresses, the iPAddress field MUST contain 32 octets similarly encoded.
4.2.1.11	Conforming CAs MUST NOT issue certificates where policy constraints is an empty sequence. That is, either the inhibitPolicyMapping field or the requireExplicitPolicy field MUST be present.
4.2.1.11	Policy Constraints: Conforming CAs MUST mark this extension as critical.
4.2.1.13	a DistributionPoint MUST NOT consist of only the reasons field; either distributionPoint or cRLIssuer MUST be present.
4.2.1.14	Conforming CAs MUST mark this Inhibit anyPolicy extension as critical.
4.2.1.15	The Freshest CRL extension MUST be marked as non-critical by conforming CAs.
4.2.2.1	Conforming CAs MUST mark this Authority Information Access extension as non-critical.
4.2.2.2	Conforming CAs MUST mark this Subject Information Access extension as non-critical.
4.1.2.5	To indicate that a certificate has no well-defined expiration date, the notAfter SHOULD be assigned the GeneralizedTime value of 99991231235959Z.
4.2.1.2	To assist applications in identifying the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates
4.2.1.3	When present, conforming CAs SHOULD mark this Key Usage extension as critical.
4.2.1.4	Conforming CAs SHOULD NOT use the noticeRef option.
4.2.1.4	Conforming CAs SHOULD use the UTF8String encoding for explicitText, but MAY use IA5String.
4.2.1.4	The explicitText string SHOULD NOT include any control characters (e.g., U+0000 to U+001F and U+007F to U+009F).
4.2.1.4	When the UTF8String encoding is used, all character sequences SHOULD be normalized according to Unicode normalization form C (NFC)
4.2.1.5	Each issuerDomainPolicy named in the policy mappings extension SHOULD also be asserted in a certificate policies extension in the same certificate.
4.2.1.5	Conforming CAs SHOULD mark this Policy Mappings extension as critical.
4.2.1.6	When including the subjectAltName extension in a certificate that has a non-empty subject distinguished name, conforming CAs SHOULD mark the subjectAltName extension as non-critical.
4.2.1.7	Where present, conforming CAs SHOULD mark this Issuer Alternative Name extension as non- critical.
4.2.1.10	SHOULD NOT impose name constraints on the x400Address, ediPartyName, or registeredID name forms.
4.2.1.12	Conforming CAs SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage KeyPurposeId is present.
4.2.1.13	The CRL Distribution Points extension SHOULD be non-critical
4.2.1.13	When present, DistributionPointName SHOULD include at least one LDAP or HTTP URI.
4.2.1.13	Conforming CAs SHOULD NOT use nameRelativeToCRLIssuer to specify distribution point names.
4.2.2.1	When the id-ad-caIssuers accessMethod is used, at least one instance SHOULD specify an accessLocation that is an HTTP [RFC 2616] or LDAP [RFC 4516] URI.
7.2	To accommodate internationalized domain names in the current structure, conforming implementations MUST convert internationalized domain names to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of RFC 3490 before storage in the dNSName field.