Re: CURLINFO_CERTINFO and TLS certificate chain availability

On 12/24/2025 11:49 AM, dogma via curl-library wrote:
>> From: Ray Satiro
>> On 12/23/2025 6:53 PM, dogma via curl-library wrote:
>>> Does CURLINFO_CERTINFO always provide the chain of certificates if it
>>> happens to be exposed by the backend, or is it more haphazard than that?
>>>
>>> If a transfer fails, I print the chain if it?s provided, but for example
>>>    I just had one that failed because the certificate has expired. No
>>> chain. This is with OpenSSL.
>> I think historically it wasn't provided unless the transfer was
>> successful, the backend supported it and CURLOPT_CERTINFO [1] was
>> enabled for the transfer. However I just tested curl master branch [2]
>> with OpenSSL and retrieving CERTINFO worked for a failed transfer. I
>> tested against a URL (https://cdn.gigya.com) that serves a certificate
>> with no matching hostname ("no alternative certificate subject name
>> matches") so the transfer fails. I tested against some other URLs with
>> different types of cert problems as well as expired certificates and I
>> still got certinfo.
> Yes, I do get certinfo for that "no alternative certificate subject name matches" site as well.


Do you have a way to reproduce the missing certs when there is an 
expired certificate error? I'm not sure I'd consider it a bug since 
certificate information is not guaranteed if the handshake fails, but 
I'd still like to know why it works for me and not for you.

I'm attaching an expired CA certificate expirted_geotrust_ca.crt that I 
used to connect to https://download.cyanogenmod.org which caused the 
transfer to fail due to "SSL certificate OpenSSL verify result: 
certificate has expired". For me it is working to show the certs when 
the transfer fails due to expired certificates.

   curl_easy_setopt(curl, CURLOPT_CAINFO, "expirted_geotrust_ca.crt");

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html