Conformidade com RFC

O Certificate Authority Service usa a ferramenta ZLint (link em inglês) para garantir que os certificados X.509 sejam válidos de acordo com as regras do RFC 5280 (links em inglês). No entanto, o serviço de CA não aplica todos os requisitos do RFC 5280, e é possível que uma CA criada com o serviço de CA emita um certificado incompatível.

O CA Service aplica os seguintes requisitos do RFC 5280.

Seção RFC 5280	Cláusula de lint
4.1.1.2	O signatureAlgorithm no Certificate PRECISA conter o mesmo identificador de algoritmo que o campo "signature" na sequência tbsCertificate (Seção 4.1.2.3).
4.1.2.1	Quando as extensões são usadas, como esperado nesse perfil, a versão PRECISA ser 3 (o valor é 2).
4.1.2.2	O número de série PRECISA ser um número inteiro positivo atribuído pela CA a cada certificado.
4.1.2.2	As CAs em conformidade NÃO podem usar valores de serialNumber com mais de 20 octetos.
4.1.2.4	O campo do emissor PRECISA conter um nome distinto (DN) não vazio.
4.1.2.5	As CAs em conformidade com esse perfil PRECISAM sempre codificar as datas de validade do certificado até o ano de 2049 como UTCTime
4.1.2.5.1	Os valores UTC PRECISAM ser expressos no horário de Greenwich (Zulu)
4.1.2.5.1	Os valores de horário UTC PRECISAM incluir segundos
4.1.2.5.2	Os valores de GeneralizedTime PRECISAM ser expressos no horário de Greenwich (Zulu)
4.1.2.5.2	GeneralizedTime PRECISA incluir segundos
4.1.2.5.2	Os valores de GeneralizedTime NÃO PODEM incluir segundos fracionários
4.1.2.6	Se o assunto for uma CA (por exemplo, a extensão de restrições básicas, conforme discutido na seção 4.2.1.9, e o valor de cA for TRUE), o campo de assunto PRECISA ser preenchido com um nome distinto não vazio correspondente ao conteúdo do campo do emissor (Seção 4.1.2.4) em todos os certificados emitidos pela CA em questão.
4.1.2.8	Os campos de identificador exclusivo PRECISAM aparecer apenas se a versão for 2 ou 3
4.1.2.8	As CAs em conformidade com esse perfil NÃO PODEM gerar certificados com identificadores exclusivos.
4.1.2.9	O campo "Extensões" só PRECISA aparecer se a versão for 3
4.2	Um certificado NÃO PODE incluir mais de uma instância de uma extensão específica.
4.2	Se a CA emite certificados com uma sequência vazia para o campo do assunto, ela PRECISA aceitar a extensão do nome alternativo do assunto.
4.2.1.1	O campo keyIdentifier da extensão AuthorityKeyIdentifier PRECISA ser incluído em todos os certificados gerados por CAs em conformidade para facilitar a criação do caminho de certificação.
4.2.1.1	As CAs em conformidade PRECISAM marcar a extensão AuthorityKeyIdentifier como não crítica.
4.2.1.2	Para facilitar a criação do caminho de certificação, o AuthorityKeyIdentifier PRECISA aparecer em todos os certificados de CA em conformidade, ou seja, todos os certificados que incluem a extensão de restrições básicas (Seção 4.2.1.9) em que o valor de cA é TRUE.
4.2.1.2	As CAs em conformidade PRECISAM marcar a extensão do identificador de chave de assunto como não crítica.
4.2.1.3	Se o bit keyCertSign for declarado, o bit cA na extensão de restrições básicas (Seção 4.2.1.9) também PRECISA ser declarado.
4.2.1.3	Quando a extensão keyUsage aparece em um certificado, pelo menos um dos bits PRECISA ser definido como 1.
4.2.1.4	Um OID de política de certificado NÃO PODE aparecer mais de uma vez em uma extensão de políticas de certificado.
4.2.1.4	Quando os qualificadores são usados com a política especial AnyPolicy, eles PRECISAM ser limitados aos qualificadores identificados nesta seção.
4.2.1.5	As políticas NÃO PODEM ser mapeadas para ou a partir do valor especial anyPolicy
4.2.1.6	Sempre que essas identidades (qualquer coisa em uma SAN) forem vinculadas a um certificado, a extensão do nome alternativo do assunto ou do emissor PRECISA ser usada.
4.2.1.6	Se o campo de assunto contiver uma sequência vazia, a CA emissora PRECISA incluir uma extensão subjectAltName marcada como crítica.
4.2.1.6	Quando a extensão subjectAltName contém um endereço de e-mail na Internet, o endereço PRECISA ser armazenado no rfc822Name.
4.2.1.6	Para a versão 4 do IP, conforme especificado na [RFC 791], a string de octetos PRECISA conter exatamente quatro octetos. Para a versão 6 do IP, conforme especificado na [RFC 2460], a string de octetos PRECISA conter exatamente dezesseis octetos.
4.2.1.6	Quando a extensão subjectAltName contém um rótulo do sistema de nomes de domínio, o nome de domínio PRECISA ser armazenado no dNSName (uma IA5String).
4.2.1.6	SANs: o dNSName PRECISA estar na "sintaxe de nome preferencial"
4.2.1.6	As extensões subjectAltName com um dNSName de " " NÃO PODEM ser usadas
4.2.1.6	o uso da representação DNS para endereços de e-mail da Internet (subscriber.example.com em vez de [e-mail]) NÃO DEVE ser usado
4.2.1.6	Quando a extensão subjectAltName contém um URI, o nome PRECISA ser armazenado em uniformResourceIdentifier (uma IA5String).
4.2.1.6	URIs SAN: o nome NÃO PODE ser um URI relativo e PRECISA seguir a sintaxe de URI e as regras de codificação especificadas na [RFC 3986].
4.2.1.6	URIs SAN: o nome PRECISA incluir um esquema (por exemplo, "http" ou "ftp") e uma parte específica do esquema.
4.2.1.6	URIs SAN que incluem uma autoridade ([RFC 3986], Seção 3.2) PRECISAM incluir um nome de domínio ou endereço IP totalmente qualificado como o host.
4.2.1.6	Se a extensão subjectAltName estiver presente, a sequência PRECISA conter pelo menos uma entrada.
4.2.1.6	CAs em conformidade NÃO PODEM emitir certificados com subjectAltNames contendo campos GeneralName vazios.
4.2.1.7	O nome alternativo do emissor PRECISA ser codificado como 4.2.1.6
4.2.1.8	Atributos do diretório do assunto: as CAs em conformidade PRECISAM marcar essa extensão como não crítica.
4.2.1.9	Quando aparece, o campo "pathLenConstraint" PRECISA ser maior ou igual a zero.
4.2.1.9	As CAs em conformidade PRECISAM incluir essa extensão em todos os certificados de CA que contêm chaves públicas usadas para validar assinaturas digitais em certificados e marcar a extensão como crítica nesses certificados.
4.2.1.9	As CAs NÃO podem incluir o campo pathLenConstraint, a menos que o booleano cA seja declarado e a extensão de uso de chaves declare o bit keyCertSign.
4.2.1.10	A extensão de restrições de nome, que PRECISA ser usada apenas em um certificado de CA, indica um espaço de nome em que todos os nomes de assunto em certificados subsequentes PRECISAM estar localizados.
4.2.1.10	Restrições de nome: as CAs em conformidade PRECISAM marcar esta extensão como crítica
4.2.1.10	As CAs em conformidade NÃO podem emitir certificados quando as restrições de nome são uma sequência vazia. Ou seja, o campo allowedSubtrees ou o excludedSubtrees PRECISA estar presente.
4.2.1.10	Nesse perfil, os campos mínimo e máximo não são usados em formulários de nome. Assim, o mínimo PRECISA ser zero, e o máximo PRECISA estar ausente.
4.2.1.10	A sintaxe de iPAddress DEVE estar conforme descrito na Seção 4.2.1.6, com as seguintes adições especificamente para restrições de nome: para endereços IPv4, o campo iPAddress de GeneralName PRECISA conter oito (8) octetos, codificados no estilo do RFC 4632 (CIDR) para representar um intervalo de endereços [RFC 4632]. Para endereços IPv6, o campo iPAddress PRECISA conter 32 octetos codificados de forma semelhante.
4.2.1.11	As CAs em conformidade NÃO PODEM emitir certificados quando as restrições da política são uma sequência vazia. Ou seja, o campo inhibitPolicyMapping ou requiredexplicitPolicy PRECISA estar presente.
4.2.1.11	Restrições de política: as CAs em conformidade PRECISAM marcar essa extensão como crítica.
4.2.1.13	um DistributionPoint NÃO pode consistir apenas no campo de motivos. O DistributionPoint ou o cRLIssuer PRECISA estar presente.
4.2.1.14	As CAs em conformidade PRECISAM marcar essa extensão Inhibit anyPolicy como crítica.
4.2.1.15	A extensão CRL mais recente PRECISA ser marcada como não crítica por CAs em conformidade.
4.2.2.1	As CAs em conformidade PRECISAM marcar essa extensão do Authority Information Access como não crítica.
4.2.2.2	As CAs em conformidade PRECISAM marcar esta extensão de acesso a informações do assunto como não crítica.
4.1.2.5	Para indicar que um certificado não tem uma data de validade bem definida, notAfter DEVE receber o valor GeneralizedTime de 99991231235959Z.
4.2.1.2	Para ajudar as inscrições a identificar o certificado de entidade final apropriado, esta extensão DEVE ser incluída em todos os certificados de entidade final
4.2.1.3	Quando presente, as CAs em conformidade DEVEM marcar essa extensão de uso de chaves como crítica.
4.2.1.4	As CAs em conformidade NÃO DEVEM usar a opçãonoticeRef.
4.2.1.4	CAs em conformidade DEVEM usar a codificação UTF8String para explicitText, mas PODE usar IA5String.
4.2.1.4	A string explicitText NÃO DEVE incluir caracteres de controle (por exemplo, U+0000 a U+001F e U+007F para U+009F).
4.2.1.4	Quando a codificação UTF8String é usada, todas as sequências de caracteres DEVEM ser normalizadas de acordo com o formato de normalização Unicode C (NFC, na sigla em inglês)
4.2.1.5	Cada emissorDomainPolicy nomeado na extensão de mapeamentos de política também DEVE ser declarado em uma extensão de políticas de certificado no mesmo certificado.
4.2.1.5	As CAs em conformidade DEVEM marcar essa extensão de mapeamentos de políticas como crítica.
4.2.1.6	Ao incluir a extensão subjectAltName em um certificado que tenha um nome distinto de assunto não vazio, as CAs em conformidade DEVEM marcar a extensão subjectAltName como não crítica.
4.2.1.7	Quando presente, as CAs em conformidade DEVEM marcar essa extensão de nome alternativo do emissor como não essencial.
4.2.1.10	NÃO DEVE impor restrições de nome aos formulários de nome x400Address, ediPartyName ou RegisterID.
4.2.1.12	As CAs em conformidade NÃO DEVEM marcar essa extensão como crítica se o anyExtendedKeyUsage KeyPurposeId estiver presente.
4.2.1.13	A extensão de pontos de distribuição de CRL DEVE não ser essencial
4.2.1.13	Quando presente, DistributionPointName DEVE incluir pelo menos um URI LDAP ou HTTP.
4.2.1.13	As CAs em conformidade NÃO DEVEM usar nameRelativeToCRLIssuer para especificar nomes de pontos de distribuição.
4.2.2.1	Quando id-ad-caIssuers accessMethod é usado, pelo menos uma instância DEVE especificar um accessLocation que seja um URI HTTP [RFC 2616] ou LDAP [RFC 4516].
7.2	Para acomodar nomes de domínio internacionalizados na estrutura atual, as implementações em conformidade PRECISAM converter nomes de domínio internacionalizados no formato de codificação compatível com ASCII (ACE, na sigla em inglês), conforme especificado na Seção 4 do RFC 3490, antes do armazenamento no campo dNSName.