Conformidade com RFC

O Certificate Authority Service usa a ferramenta ZLint para garantir que os certificados X.509 sejam válidos de acordo com as regras da RFC 5280. No entanto, o CA Service não impõe todos os requisitos da RFC 5280, e é possível que uma CA criada usando o CA Service emita um certificado não compatível.

O Certificate Authority Service impõe os seguintes requisitos da RFC 5280.

Seção da RFC 5280	Cláusula de lint
4.1.1.2	O signatureAlgorithm no certificado precisa conter o mesmo identificador de algoritmo do campo de assinatura na sequência tbsCertificate (seção 4.1.2.3).
4.1.2.1	Quando as extensões são usadas, como esperado neste 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 maiores que 20 octetos.
4.1.2.4	O campo "issuer" PRECISA conter um nome distinto (DN) não vazio.
4.1.2.5	As CAs que obedecem a esse perfil SEMPRE precisam codificar as datas de validade do certificado até o ano de 2049 como UTCTime.
4.1.2.5	Para indicar que um certificado não tem uma data de validade bem definida, o notAfter DEVE receber o valor GeneralizedTime de 99991231235959Z.
4.1.2.5.1	Os valores UTCTime precisam ser expressos no horário de Greenwich (Zulu).
4.1.2.5.1	Os valores de UTCTime PRECISAM incluir segundos
4.1.2.5.2	Os valores 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 GeneralizedTime NÃO PODEM incluir segundos fracionados
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, estiver presente e o valor de cA for TRUE), o campo de assunto DEVERÁ ser preenchido com um nome distinto não vazio que corresponda ao conteúdo do campo de emissor (seção 4.1.2.4) em todos os certificados emitidos pela CA do assunto.
4.1.2.8	Os campos de identificador exclusivo SÓ podem aparecer se a versão for 2 ou 3
4.1.2.8	As CAs que obedecem a esse perfil NÃO PODEM gerar certificados com identificadores exclusivos.
4.1.2.9	O campo "extensions" SÓ DEVE 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 emitir certificados com uma sequência vazia para o campo "assunto", ela PRECISA oferecer suporte à extensão de 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 construçã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 construção do caminho de certificação, o authorityKeyIdentifier precisa aparecer em todos os certificados de CA em conformidade, ou seja, todos os certificados, incluindo 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 do assunto como não crítica.
4.2.1.2	Para ajudar os aplicativos a identificar o certificado de entidade final adequado, essa extensão DEVE ser incluída em todos os certificados de entidade final.
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 DEVERÁ 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.3	Quando presente, as CAs em conformidade DEVEM marcar essa extensão de uso de chave como crítica.
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.4	As CAs em conformidade NÃO DEVEM usar a opção noticeRef.
4.2.1.4	As CAs em conformidade DEVEM usar a codificação UTF8String para explicitText, mas PODEM 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 a U+009F).
4.2.1.4	Quando a codificação UTF8String é usada, todas as sequências de caracteres PRECISAM ser normalizadas de acordo com a forma de normalização Unicode C (NFC).
4.2.1.5	As políticas NÃO PODEM ser mapeadas para ou do valor especial anyPolicy.
4.2.1.5	Cada issuerDomainPolicy nomeada na extensão de mapeamentos de políticas TAMBÉM DEVE ser declarada 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	Sempre que essas identidades (qualquer coisa em um SAN) forem vinculadas a um certificado, a extensão de nome alternativo do assunto (ou nome alternativo do emissor) DEVE ser usada.
4.2.1.6	Se o campo "Assunto" contiver uma sequência vazia, a CA emissora DEVE 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 da Internet, ele precisa ser armazenado no rfc822Name.
4.2.1.6	Para a versão 4 do IP, conforme especificado na [RFC 791], a string de octeto precisa conter exatamente quatro octetos. Para a versão 6 do IP, conforme especificado na [RFC 2460], a string de octeto precisa conter exatamente 16 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	Não use extensões subjectAltName com um dNSName de " ".
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 no uniformResourceIdentifier (uma IA5String).
4.2.1.6	URIs SAN: o nome NÃO PODE ser um URI relativo e precisa seguir a sintaxe e as regras de codificação de URI especificadas em [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	Os URIs SAN que incluem uma autoridade ([RFC 3986], seção 3.2) precisam incluir um nome de domínio totalmente qualificado ou um endereço IP como host.
4.2.1.6	Se a extensão subjectAltName estiver presente, a sequência precisará conter pelo menos uma entrada.
4.2.1.6	As ACs em conformidade NÃO PODEM emitir certificados com subjectAltNames que contenham campos GeneralName vazios.
4.2.1.6	Ao incluir a extensão subjectAltName em um certificado que tem 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	O nome alternativo do emissor PRECISA ser codificado como em 4.2.1.6
4.2.1.7	Quando presente, as CAs em conformidade DEVEM marcar essa extensão de nome alternativo do emissor como não crítica.
4.2.1.8	Atributos do diretório de assunto: as CAs em conformidade precisam marcar essa extensão como não crítica.
4.2.1.9	Quando ele 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 chave declare o bit "keyCertSign".
4.2.1.10	A extensão de restrições de nome, que SÓ pode ser usada em um certificado de CA, indica um namespace em que todos os nomes de assunto nos certificados subsequentes em um caminho de certificação PRECISAM estar localizados.
4.2.1.10	Restrições de nome: as CAs em conformidade precisam marcar essa extensão como crítica
4.2.1.10	As CAs em conformidade NÃO PODEM emitir certificados em que as restrições de nome são uma sequência vazia. Ou seja, o campo "permittedSubtrees" ou "excludedSubtrees" precisa estar presente.
4.2.1.10	Nesse perfil, os campos "mínimo" e "máximo" não são usados com nenhuma forma de nome. Portanto, o mínimo precisa ser zero e o máximo precisa estar ausente.
4.2.1.10	A sintaxe de iPAddress precisa ser conforme descrito na seção 4.2.1.6, com as seguintes adições específicas 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 maneira semelhante.
4.2.1.10	NÃO DEVE impor restrições de nome aos formulários x400Address, ediPartyName ou registeredID.
4.2.1.11	As ACs em conformidade NÃO PODEM emitir certificados em que as restrições de política sejam uma sequência vazia. Ou seja, o campo "inhibitPolicyMapping" ou "requireExplicitPolicy" 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.12	As CAs em conformidade NÃO DEVEM marcar essa extensão como crítica se o KeyPurposeId anyExtendedKeyUsage estiver presente.
4.2.1.13	Um DistributionPoint NÃO PODE consistir apenas no campo "reasons"; "distributionPoint" ou "cRLIssuer" precisam estar presentes.
4.2.1.13	A extensão de pontos de distribuição de CRL NÃO DEVE ser crítica
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 ponto de distribuição.
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 de 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 de acesso a informações de autoridade como não crítica.
4.2.2.1	Quando o accessMethod id-ad-caIssuers é usado, pelo menos uma instância DEVE especificar um accessLocation que seja um URI HTTP [RFC 2616] ou LDAP [RFC 4516].
4.2.2.2	As CAs em conformidade precisam marcar essa extensão de acesso a informações do assunto como não crítica.
7.2	Para acomodar nomes de domínio internacionalizados na estrutura atual, as implementações em conformidade PRECISAM converter nomes de domínio internacionalizados para o formato de codificação compatível com ASCII (ACE) conforme especificado na seção 4 da RFC 3490 antes do armazenamento no campo dNSName.