Como verificar se um servidor vai aceitar seu certificado de cliente

Uma forma de autenticar aplicações clientes para aplicações servidoras que está desaparecendo mas ainda é bastante comum é o uso de certificados TLS/SSL de cliente. Desse modo você pode fazer uso da infra-estrutura HTTPS existente e apenas verificar o número de série do certificado do cliente contra uma lista conhecida de aplicações autorizadas.

Isso é comumente feito em um contexto corporativo onde o processo de emissão de certificados pode ser delegado para um terceiro. Mas isso também significa que a Autoridade Certificadora pode não ser imediatamente aceita pela infra-estrutura da aplicação servidora.

Quando isso acontece, talvez o cliente não tenha 100% de certeza de que o servidor vai aceitar seu certificado. Na hora de renovar certificados — e talvez até seja necessário trocar de autoridade — a ansiedade invariavelmente ataca!

Faça isso então

O OpenSSL vai te ajudar, claro. Mas o OpenSSL não é exatamente fácil de lidar.

O comando que você precisa é openssl verify. Ele recebe como entrada uma lista de autoridades certificadoras, que vem da equipe da aplicação servidora, e um certificado de cliente, que vem da equipe da aplicação cliente.

Com esses dois arquivos em mãos, aqui está o que você vai precisar dizer no seu shell preferido:

$ openssl verify \
    -no-CApath \
    -CAfile certificate_authority_list.pem \
    client_certificate.pem

Não esqueça de incluir a flag -noCApath ou então o OpenSSL vai usar a trust store do computador além da lista de autoridades certificadores fornecida. Você não vai conseguir uma resposta precisa assim. Especialmente se o certificado foi assinado por uma autoridade publicamente reconhecida.

Nota de rodapé sobre formatos de arquivo: Estamos o tempo todo assumindo que os arquivos estão em formato PEM. Arquivos PEM são aqueles que contém linhas -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----

Em openssl-ês uma marca verde de sucesso tem essa cara:

client_certificate.pem: OK

Se você receber algo parecido com isso, pode parar por aqui que já está tudo certo!

E se meu certificado de cliente não passar no teste?

Ao rodar o openssl verify, você pode tomar um erro:

C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
error 2 at 1 depth lookup: unable to get issuer certificate
error client_certificate.pem: verification failed

Assumindo que está tudo certo com seu arquivo de certificado, qualquer erro significa problema no arquivo das autoridades certificadoras. Este que foi mostrado aqui significa que a autoridade certificadora (AC) de primeiro nível é confiável, mas a de segundo nível não. O OpenSSL inicia a contagem de zero, "error X at 1 depth lookup" significa que a busca depth 0 foi bem sucedida e houve um erro na busca seguinte.

Vamos precisar de um caminho limpo até uma AC raiz a partir do certificado do cliente. Em outras palavras, o certificado de cliente precisa ser assinado por uma autoridade confiável e o certificado dessa autoridade _também precisa ser assinado por uma autoridade confiável. E assim por adiante até chegarmos em um certificado que está assinado por si mesmo. Estas são as ACs raiz.

Para verificar que AC assina o certificado, você pode usar outro commando OpenSSL:

$ openssl x509 -in client_certificate.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ...
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
        ...
        X509v3 extensions:
            Authority Information Access: 
                CA Issuers - URI:http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt
                OCSP - URI:http://ocsp.globalsign.com/gsrsaovsslca2018
            X509v3 Authority Key Identifier: 
                keyid:F8:EF:7F:F2:CD:78:67:A8:DE:6F:8F:24:8D:88:F1:87:03:02:B3:EB
            ...

E novamente com o certificado da AC:

$ openssl x509 -in gsrsaovsslca2018.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            01:ee:5f:22:1d:fc:62:3b:d4:33:3a:85:57
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        Subject: C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
        ...
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                F8:EF:7F:F2:CD:78:67:A8:DE:6F:8F:24:8D:88:F1:87:03:02:B3:EB
            X509v3 Authority Key Identifier: 
                keyid:8F:F0:4B:7F:A8:2E:45:24:AE:4D:50:FA:63:9A:8B:DE:E2:DD:1B:BC
            ...

Felizmente, essa é uma cadeia com apenas duas AC. Só precisamos de mais uma verificação:

$ openssl x509 -in Root-R3.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:21:58:53:08:a2
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        Subject: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        ...
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                8F:F0:4B:7F:A8:2E:45:24:AE:4D:50:FA:63:9A:8B:DE:E2:DD:1B:BC
        ...

Está vendo como o campo X509v3 Authority Key Identifier em um certificado corresponde ao campo X509v3 Subject Key Identifier do certificado seguinte? E que o Issuer e o Subject no último são os mesmos? Isso significa que nossa cadeia de certificados está íntegra.

Se você tiver sorte, a autoridade certificadora em si vai prover um arquivo de cadeia de certificados em seu site. Esse arquivo inclui todos os certificados de AC até o raiz. Se não, você vai precisar costurar arquivos de AC:

$ cat gsrsaovsslca2018.pem Root-R3.pem > new_certificate_authority_list.pem

Teste esse arquivo novo usando o openssl verify (só por precaução), peça à equipe do servidor para atualizar seu arquivo de autoridades e boa viagem com SSL!