Início / server / Perguntas / 306345
Accepted
Remy Blank
Asked: 2011-08-31 00:34:09 +0800 CST

Expiração e renovação do certificado raiz da autoridade de certificação

  • 772

Em 2004, criei uma pequena autoridade de certificação usando OpenSSL no Linux e os scripts de gerenciamento simples fornecidos com o OpenVPN. De acordo com os guias que encontrei na época, defini o período de validade do certificado CA raiz para 10 anos. Desde então, assinei muitos certificados para túneis OpenVPN, sites e servidores de e-mail, todos com validade de 10 anos (isso pode estar errado, mas eu não sabia melhor na época).

Encontrei muitos guias sobre como configurar uma CA, mas apenas muito pouca informação sobre seu gerenciamento e, em particular, sobre o que deve ser feito quando o certificado de CA raiz expirar, o que acontecerá em algum momento de 2014. Portanto, tenho o seguinte perguntas:

  • Os certificados cujo período de validade se estende após a expiração do certificado da CA raiz se tornarão inválidos assim que este expirar ou continuarão válidos (porque foram assinados durante o período de validade do certificado da CA)?
  • Quais operações são necessárias para renovar o certificado de CA raiz e garantir uma transição suave ao longo de sua expiração?
    • Posso, de alguma forma, assinar novamente o certificado CA raiz atual com um período de validade diferente e carregar o certificado recém-assinado para os clientes para que os certificados do cliente permaneçam válidos?
    • Ou preciso substituir todos os certificados de cliente por novos assinados por um novo certificado de CA raiz?
  • Quando o certificado CA raiz deve ser renovado? Perto do vencimento ou um tempo razoável antes do vencimento?
  • Se a renovação do certificado de CA raiz se tornar um trabalho importante, o que posso fazer melhor agora para garantir uma transição mais suave na próxima renovação (exceto definir o período de validade para 100 anos, é claro)?

A situação é um pouco mais complicada pelo fato de que meu único acesso a alguns dos clientes é através de um túnel OpenVPN que usa um certificado assinado pelo certificado CA atual, então se eu tiver que substituir todos os certificados do cliente, precisarei copiar os novos arquivos para o cliente, reinicie o túnel, cruze os dedos e torça para que apareça depois.

certificate-authority openssl

7 respostas

  1. Best Answer

    Manter a mesma chave privada em sua CA raiz permite que todos os certificados continuem a ser validados com sucesso em relação à nova raiz; tudo o que é exigido de você é confiar na nova raiz.

    A relação de assinatura do certificado é baseada em uma assinatura da chave privada; manter a mesma chave privada (e, implicitamente, a mesma chave pública) enquanto gera um novo certificado público, com um novo período de validade e quaisquer outros novos atributos alterados conforme necessário, mantém a relação de confiança em vigor. As CRLs também podem continuar do certificado antigo para o novo, pois são, como certificados, assinados pela chave privada.

    Então, vamos verificar!

    Faça uma CA raiz:

    openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

    Gere um certificado filho a partir dele:

    openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

    Assine o certificado filho:

    openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

    Tudo pronto lá, relação de certificado normal. Vamos verificar a confiança:

    # openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

    Ok, então, agora vamos dizer que 10 anos se passaram. Vamos gerar um novo certificado público a partir da mesma chave privada raiz.

    openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

    E.. funcionou?

    # openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

    Mas por que? São arquivos diferentes, certo?

    # sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

    Sim, mas isso não significa que a nova chave pública não corresponda criptograficamente à assinatura do certificado. Números de série diferentes, mesmo módulo:

    # openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

    Vamos um pouco mais longe para verificar se está funcionando na validação de certificados do mundo real.

    Inicie uma instância do Apache e vamos tentar (estrutura de arquivos debian, ajuste conforme necessário):

    # cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

    Vamos definir essas diretivas em uma VirtualHostescuta em 443 - lembre-se, o newroot.pemcertificado raiz nem existia quando cert.pemfoi gerado e assinado.

    SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

    Vamos verificar como o openssl o vê:

    # openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

    Ok, e que tal um navegador usando a API de criptografia da MS? Tem que confiar na raiz, primeiro, depois está tudo bem, com o número de série da nova raiz:

    nova raiz

    E ainda devemos estar trabalhando com a raiz antiga também. Mude a configuração do Apache:

    SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

    Faça uma reinicialização completa no Apache, um recarregamento não alternará os certificados corretamente.

    # openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

    E, com o navegador da API de criptografia MS, o Apache está apresentando a raiz antiga, mas a nova raiz ainda está no armazenamento raiz confiável do computador. Ele o encontrará automaticamente e validará o certificado em relação à raiz confiável (nova), apesar do Apache apresentar uma cadeia diferente (a raiz antiga). Depois de remover a nova raiz das raízes confiáveis ​​e adicionar o certificado raiz original, tudo está bem:

    raiz velha

    Então é isso! Mantenha a mesma chave privada ao renovar, troque a nova raiz confiável e praticamente tudo funciona . Boa sorte!

    • 181

  2. Percebi que as extensões de CA podem estar faltando no certificado renovado da chave de CA original. Isso funcionou mais apropriadamente para mim (cria um ./renewedselfsignedca.confonde as extensões de CA v3 são definidas ca.keye ca.crtsão consideradas a chave e o certificado originais da CA):

    openssl x509 -x509toreq -in ca.crt -signkey ca.key -out \
    renewedselfsignedca.csr

echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier=
hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > \
    renewedselfsignedca.conf

openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey \
    ca.key -out renewedselfsignedca.crt \
    -extfile ./renewedselfsignedca.conf \
    -extensions v3_ca
    • 18

  3. Modo básico para estender o período válido de root (você precisa do X.509 público e da chave privada associada):

    Gere o CSR do X.509 público e da chave privada:

    openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

    Assine novamente o CSR com a chave privada:

    openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365
    • 4

  4. @Bianconiglio plus -set_serialfuncionou para mim. Meu servidor é apenas intranet, então não estou me preocupando muito com os efeitos colaterais e agora tenho tempo para trabalhar em uma solução "adequada".

    Eu usei o seguinte script configurável. Basta definir as variáveis CACRT​​, CAKEYe NEWCA.

    # WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout
    • 3

  5. Quando seu certificado raiz expira, os certificados que você assinou com ele também expiram. Você terá que gerar um novo certificado raiz e assinar novos certificados com ele. Se você não quiser repetir o processo a cada poucos anos, a única opção real é estender a data de validade do certificado raiz algo como dez ou vinte anos: A raiz que gerei para meu próprio uso, estabeleci vinte anos.

    Você não pode "renovar" um certificado raiz. Tudo o que você pode fazer é gerar um novo.

    Gere uma nova raiz pelo menos um ou dois anos antes que a antiga expire, para que você tenha tempo de mudar sem estar contra uma parede do tempo se algo der errado. Dessa forma, você sempre pode voltar temporariamente para os certificados antigos até resolver seus problemas iniciais com o novo.

    No que diz respeito aos túneis VPN, eu configuraria alguns servidores de teste para experimentar, para que você entenda exatamente o que precisa fazer antes de fazer isso com a máquina de um cliente.

    • 1

  6. Tivemos o mesmo problema, e isso foi no nosso caso porque o servidor Debian estava desatualizado e o openSSL teve esse problema:

    https://en.wikipedia.org/wiki/Year_2038_problem

    A última versão do OpenSSL disponível para o Debian 6 traz esse problema. Todos os certificados criados após 23.01.2018 produzem um Vality: for 1901 year !

    A solução é atualizar o OpenSSL. Você pode criar novamente os arquivos de configuração (com os certificados) para os clientes.

    • 0

  7. A resposta https://serverfault.com/a/308100/971795 parece sugerir que não é necessário renovar a chave privada - apenas renovar o certificado de chave pública é suficiente. No entanto, é uma prática recomendada alternar a chave privada da CA raiz de vez em quando.

    O procedimento é "substituir" a CA antiga por uma nova (não apenas o certificado de chave pública, mas toda a CA),

    1. Crie uma nova CA e comece a emitir novos certificados a partir dela
    2. Desabilite a emissão na CA antiga, MAS MANTENHA a revogação/validação do certificado
    3. Aguarde até que todos os certificados emitidos pela antiga CA expirem (você pode gerar um relatório de auditoria na antiga CA)
    4. desligue o CA antigo

    Observe que a etapa 2, 3 garante a transição suave da antiga para a nova CA.

    Para obter mais detalhes, consulte https://docs.aws.amazon.com/acm-pca/latest/userguide/ca-lifecycle.html#ca-succession

    • 0

relate perguntas