O problema da emissão

Você pode gerar um par de chaves por conta própria em segundos, mas uma chave pública nua não prova nada sobre quem você é (o problema de vínculo do artigo de anatomia). Para obter um certificado, você precisa de uma autoridade certificadora em que uma parte confiante já confia para atestar que esta chave pública pertence ao seu nome. A Requisição de Assinatura de Certificado (Certificate Signing Request) é como você pede isso, sem nunca entregar sua chave privada.

O que uma CSR contém

Uma CSR é, ela mesma, uma estrutura ASN.1, definida pelo PKCS#10 (RFC 2986) e geralmente enviada como um bloco PEM rotulado CERTIFICATE REQUEST. Ela carrega:

  • o sujeito que você está requisitando (os nomes que deveriam acabar no certificado),
  • sua chave pública, e
  • uma assinatura sobre a requisição, feita com a chave privada correspondente.

Essa última parte é o detalhe engenhoso. Ao assinar a requisição com a chave privada, você prova que de fato detém a chave que forma par com a chave pública que submeteu, tudo sem revelar a própria chave privada. A chave privada nunca deixa seu controle, que é exatamente como deveria ser, porque qualquer um que a tenha pode se passar por você.

A estrutura PKCS#10, campo a campo

Por baixo desse resumo em três partes, o PKCS#10 define uma forma ASN.1 precisa. A CertificationRequest externa é uma SEQUENCE de exatamente três coisas: as informações da requisição, o algoritmo de assinatura e a própria assinatura.

CertificationRequest ::= SEQUENCE {
  certificationRequestInfo  CertificationRequestInfo,
  signatureAlgorithm        AlgorithmIdentifier,
  signature                 BIT STRING }

CertificationRequestInfo ::= SEQUENCE {
  version        INTEGER,                -- sempre v1 (0)
  subject        Name,                   -- o nome distinto que você requisita
  subjectPKInfo  SubjectPublicKeyInfo,   -- algoritmo + os bits da sua chave pública
  attributes     [0] Attributes }        -- tudo o mais que você pede

O certificationRequestInfo é a metade "a ser assinada": seu nome de sujeito, sua chave pública embrulhada na mesmíssima estrutura SubjectPublicKeyInfo que mais tarde aparecerá no certificado finalizado (veja o artigo de anatomia), e um conjunto de attributes. A assinatura é calculada sobre a codificação DER dessa metade usando sua chave privada, o que prova mecanicamente a posse da chave descrita acima.

O conjunto de attributes é onde ficam as requisições interessantes. Um certificado moderno identifica um servidor por seus Subject Alternative Names, não pelo common name do sujeito, e esses SANs viajam aqui dentro do atributo extensionRequest do PKCS#9, que é um contêiner para as extensões X.509v3 que você gostaria que a CA copiasse para o certificado. Quando o decodificador de CSR mostra os SANs ou usos de chave requisitados, ele os está lendo a partir desse atributo. (A versão 1.7 do PKCS#10, na RFC 2986, torna obsoleta a versão 1.5 mais antiga da RFC 2314; a estrutura acima é o que toda ferramenta atual emite.)

A CA é a autoridade, não o requisitante

Um ponto crucial: a CSR é uma requisição, e a CA é livre para honrar partes dela e ignorar outras. Você pode pedir qualquer sujeito e quaisquer extensões que quiser, mas a CA decide o que o certificado emitido de fato diz. Ela definirá o período de validade conforme as regras atuais, escolherá o número de série, e incluirá apenas os nomes e usos que está disposta a atestar. A assinatura da CA, não sua requisição, é o que dá ao certificado final sua autoridade. Esta separação é por que uma CSR cheia de campos ambiciosos não lhe dá um certificado cheio deles.

Como a CA decide confiar em você

Antes de assinar, a CA valida que você tem direito aos nomes que pediu, e quão minuciosamente depende do tipo de certificado:

  • Validado por Domínio (DV) prova apenas que você controla o domínio. Esta é a esmagadora maioria dos certificados TLS hoje.
  • Validado por Organização (OV) e Validação Estendida (EV) adicionalmente examinam a entidade legal por trás do domínio, a Subject Identity Information que aparece no certificado.

Para DV, a CA o desafia a demonstrar controle do domínio. Métodos comuns são colocar um arquivo específico em uma URL no site (HTTP-01), publicar um registro DNS TXT específico (DNS-01), ou responder a um e-mail enviado a um endereço no domínio. Passar no desafio é o que convence a CA de que a chave pública na sua CSR deveria ser vinculada àquele nome.

Certificados autoassinados pulam a CA

Se você assina sua própria CSR com sua própria chave em vez de enviá-la a uma CA, você obtém um certificado autoassinado, onde o Issuer é igual ao Subject. Ele não carrega nenhuma autoridade externa, porque a única coisa atestando por ele é ele mesmo, mas é perfeitamente útil para desenvolvimento local, serviços internos com seu próprio repositório de confiança, ou para atuar como a raiz de uma PKI privada. A ferramenta sinaliza quando um certificado é autoemitido, o que lhe diz imediatamente que sua confiança vem de algum lugar que não uma CA pública.

ACME: automatizando a troca

Fazer tudo isto à mão, repetidamente, é exatamente o que a mudança para tempos de vida curtos de certificado torna impossível (veja o artigo de revogação). O protocolo ACME (RFC 8555), popularizado pelo Let's Encrypt, automatiza toda a conversa: um cliente gera o par de chaves e a CSR, prova o controle do domínio através de HTTP-01 ou DNS-01 automaticamente, recebe o certificado, e repete antes de cada expiração, sem nenhum humano envolvido. O ACME é a razão pela qual milhões de sites podem rodar certificados que se renovam a cada poucas semanas, e é a espinha dorsal operacional do futuro de certificados de vida curta.

Uma requisição se torna uma credencial

O arco é simples de enunciar. Você detém um par de chaves. Uma CSR pede a uma CA que ateste a metade pública, provando ao longo do caminho que você detém a metade privada. A CA checa que você controla o nome, então emite um certificado cuja autoridade vem da assinatura da CA, não de qualquer coisa que você escreveu na requisição. Inspecionar o resultado com um decodificador lhe mostra o vínculo que a CA de fato fez, que é todo o propósito do exercício: transformar uma chave anônima em uma chave com um nome confiável anexado.