Como verificar se um servidor vai aceitar seu certificado de cliente
Tags: tutorial, security, crypthography, certificate
Published: 2020-10-01 19:02:35

---
title: Como verificar se um servidor vai aceitar seu certificado de cliente
published: true
description: 
tags: tutorial, security, crypthography, certificate
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/1tsiv9mejtyu00m2qmly.png
---
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 &mdash; e talvez até seja necessário trocar de autoridade &mdash; 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.

![Diagrama de duas equipes, uma equipe do servidor e a outra do cliente, fornecendo um arquivo de autoridades e um arquivo de certificado respectivamente para o comando openssl verify que cospe uma marca de sucesso verde](https://dev-to-uploads.s3.amazonaws.com/i/y6r8tyo4f761fvnw8d9h.png)

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!