Seeking ground truth on TLS certificates and MacOS - browser, curl, openssl compared

On a Mac, High Sierra 10.13.5, I'm seeing a difference in TLS certification validation. Chrome and Safari are happy with TLS validation when visiting https://www.visitflorida.com. Also, curl has no complaints and I am NOT using '-k'. However, openssl complains that it cannot find the intermediate certificate when trying this openssl s_client -connect www.visitflorida.com:443 < /dev/null | openssl x509 -subject -noout. I have used both the base openssl and brew-installed one.

I have tried to add in -CAfile intermediate.pem (where I downloaded the intermediate certificate from TrustWave). Even though the intermediate certificate does not appear anywhere in my KeyChain, I have exported my KeyChain System Roots into a single file and tried that via -CAfile also. Nothing is working. The only filesystem location I see certificates is /etc/ssl/cert.pem and when I specify that via -CAfile, it still fails.

Someone has suggested that my browsers and curl have a looser requirement for TLS validation than openssl. Is that really the case? I have a hard time believing it. Can anyone help me explain this behavior?

BTW, I know this can be resolved by including the intermediate certificate with the endpoint certificate on the TLS endpoint for www.visitflorida.com. Now if we could just find that missing key file!

Browser happiness: screenshot of browser validation

Curl log: curl output

1
задан 19 June 2018 в 19:53
1 ответ

Браузеры, такие как Internet Explorer / Edge, Chrome и Safari, будут искать в поле caIssuer расширений AIA URL, откуда они могут загрузить сертификат вышестоящего центра сертификации, если он не предоставлен сервером. во время установления связи TLS.

В сертификате вашего веб-сайта поле caIssuer установлено на http://ssl.trustwave.com/issuers/OVCA2_L1.crt , поэтому все вышеперечисленные браузеры будут загружать его с этого URL-адреса и используйте его для построения цепочки.

Инструменты командной строки, такие как OpenSSL s_client , не будут использовать caIssuer для загрузки этого дополнительного сертификата, отсюда и ситуация, свидетелем которой вы стали. Если бы вы попробовали Mozilla Firefox, вы бы заметили то же самое, поскольку Mozilla отказывается использовать это расширение.

Поле caIssuer в конечном итоге скрывает реальную проблему, а именно плохой администратор сервера. RFC 5246, раздел 7.4.2 диктует, что сервер должен отправить certificate_list , состоящий из его собственного сертификата, за которым следуют любые промежуточные сертификаты CA.

3
ответ дан 3 December 2019 в 18:27

Теги

Похожие вопросы