Назад | Перейти на главную страницу

Сертификаты ECDSA не проходят проверку с помощью curl и Firefox

Я застрял на проблеме в течение 2 дней, касающихся сертификатов, когда некоторые клиенты подключаются, а некоторые другие не проходят проверку сертификата.

Я работаю над CentOS 7.3 и Nginx 1.15.4. У меня есть сертификаты трех уровней, которые я создаю:

Корневой CA, ECDSA на secp384r1 + sha256
- Промежуточный CA, RSA 2048 + sha256
  - Сертификат сервера, RSA 2048 + sha256

Корневой ЦС является доверенным в системе, промежуточный ЦС и сертификаты сервера объединены в один файл, и Nginx настроен на их использование:

ssl_certificate /etc/nginx/ssl_certs/server-chain.crt;
ssl_certificate_key /etc/nginx/ssl_certs/server.key;
ssl_protocols TLSv1.2 ;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!SSLv3;
ssl_prefer_server_ciphers on;
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

Теперь Nginx готов начать с этой конфигурации, и я могу устранить неполадки с помощью openssl:

$ openssl s_client -connect www.example.com:39200 < /dev/null 2>&1
CONNECTED(00000003)
depth=2 C = GB, ST = London, L = London, O = Example Ltd, OU = Example Hosting Team, CN = Example Root Certificate Authority, emailAddress = info@Example.com
verify return:1
depth=1 C = GB, ST = London, L = London, O = Example Ltd, OU = Example Hosting Team, CN = Example Intermediate CA for project example, emailAddress = info@Example.com
verify return:1
depth=0 C = GB, ST = London, L = London, O = Example Ltd, OU = Example Hosting Team, CN = www.example.com, emailAddress = info@Example.com
verify return:1
---
Certificate chain
 0 s:/C=GB/ST=London/L=London/O=Example Ltd/OU=Example Hosting Team/CN=www.example.com/emailAddress=info@Example.com
   i:/C=GB/ST=London/L=London/O=Example Ltd/OU=Example Hosting Team/CN=Example Intermediate CA for project example/emailAddress=info@Example.com
 1 s:/C=GB/ST=London/L=London/O=Example Ltd/OU=Example Hosting Team/CN=Example Intermediate CA for project example/emailAddress=info@Example.com
   i:/C=GB/ST=London/L=London/O=Example Ltd/OU=Example Hosting Team/CN=Example Root Certificate Authority/emailAddress=info@Example.com
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/C=GB/ST=London/L=London/O=Example Ltd/OU=Example Hosting Team/CN=www.example.com/emailAddress=info@Example.com
issuer=/C=GB/ST=London/L=London/O=Example Ltd/OU=Example Hosting Team/CN=Example Intermediate CA for project example/emailAddress=info@Example.com
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2630 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: EEE677FB7C38DF8AEBEF68D22E67499D8D05710D819D5AB92BEF1B0A009DD818
    Session-ID-ctx:
    Master-Key: E423843C77F304B5D1D384DEA115AA2320128BCC824EC2B1C2F02D63A4F7B1671602F96C50DFFB9B7674C25466CF6162
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1538060858
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

Обратите внимание Verify return code: 0 (ok) и тот факт, что openssl использует системное хранилище доверенных сертификатов для проверки моей цепочки.

Я тестировал сертификаты также в Microsoft Edge, он работает, с сертификатом проблем нет.

Но другие клиенты сильно жалуются, как curl и Firefox, и я не могу заставить их работать. Вот завиток:

curl -v --cacert Example_root_ca.crt https://example-elastic-data-vm.Example.com:39200
* About to connect() to example-elastic-data-vm.Example.com port 39200 (#0)
*   Trying 192.168.0.123...
* Connected to example-elastic-data-vm.Example.com (192.168.0.123) port 39200 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: Example_root_ca.crt
  CApath: none
* Server certificate:
*       subject: E=info@Example.com,CN=example-elastic-data-vm.Example.com,OU=Example Hosting Team,O=Example Ltd,L=London,ST=London,C=GB
*       start date: Sep 27 14:53:14 2018 GMT
*       expire date: Sep 26 14:53:14 2020 GMT
*       common name: example-elastic-data-vm.Example.com
*       issuer: E=info@Example.com,CN=Example Intermediate CA for project example,OU=Example Hosting Team,O=Example Ltd,L=London,ST=London,C=GB
* NSS error -8182 (SEC_ERROR_BAD_SIGNATURE)
* Peer's certificate has an invalid signature.
* Closing connection 0
curl: (60) Peer's certificate has an invalid signature.
...

пока Firefox развлекает меня этой ошибкой:

An error occurred during a connection to example-elastic-data-vm.example.com:39200. security library: improperly formatted DER-encoded message. Error code: SEC_ERROR_BAD_DER

Для меня это похоже на проблемы совместимости. Я провел много исследований и тестов:

MS Windows с радостью проверяет всю цепочку
OpenSSL успешно проверяет всю цепочку
Протестировано с использованием всех сертификатов RSA: работает! Но в моей компании мы предпочитаем ECDSA.
Протестировано в разных браузерах / клиентах: как уже упоминалось, он работает с openssl и Edge, но не с curl и Firefox.
Изучены рекомендации по совместимости и ошибки
Тестировал разные кривые, такие как secp256r1, secp384r1 и prime256v1, но без шансов
Пробовал различные алгоритмы подписи, использование ключей, расширенное использование ключей, основные ограничения на сертификат. Те же результаты.
Явное указание на ЦС при использовании curl

Я больше не знаю, куда биться головой, кто-нибудь может указать мне правильное направление?

ОБНОВИТЬ: Я создал тестовые очищенные сертификаты, чтобы я мог загрузить их сюда:

НОТА: Вывод команд был очищен с помощью «Пример», поэтому некоторые имена могут быть отключены