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");
expired_geotrust_ca.crt
Description: application/x509-ca-cert
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
