Re: curl-7.84.0_9-win64-mingw - SChannel problem - The certificate chain was issued by an authority that is not trusted.

From: Ray Satiro via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 29 Aug 2022 13:56:28 -0400

On 8/29/2022 11:59 AM, Krüger, Carsten via curl-library wrote:
> I've trying to understand a windows specific problem regarding certificates.
>
> I'd like to use the SChannel backend.
>
> I'm enforcing the usage of SChannel via environment variable
>
> PS C:\Users\ckruegeradi\curl-7.84.0_9-win64-mingw\bin> [System.Environment]::SetEnvironmentVariable('CURL_SSL_BACKEND','schannel',[System.EnvironmentVariableTarget]::Process)
> PS C:\Users\ckruegeradi\curl-7.84.0_9-win64-mingw\bin> .\curl.exe -ivhttps://tfs.de.kworld.kpmg.com -debug
> * Trying 10.145.235.171:443...
> * Connected to tfs.de.kworld.kpmg.com (10.145.235.171) port 443 (#0)
> * schannel: disabled automatic use of client certificate
> * ALPN: offers h2
> * ALPN: offers http/1.1
> * schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
> * Closing connection 0
> curl: (60) schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
> More details here:https://curl.se/docs/sslcerts.html
>
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.
> ----
>
> My problem is now the following.
> Windows validates the certificate perfectly fine.
> If I use Internet Explorer to browse the site I'll get a perfectly valid chain and same for Powershell
> ----
> PS C:\Users\ckruegeradi\curl-7.84.0_9-win64-mingw\curl-7.84.0_9-win64-mingw\bin> Invoke-WebRequest -UseBasicParsing"https://tfs.de.kworld.kpmg.com" -UseDefaultCredentials
>
>
> StatusCode : 200
> StatusDescription : OK
> ----
>
> If I revert back to openssl backend, the corporate CA is missing (expected)
>
> PS C:\Users\ckruegeradi\curl-7.84.0_9-win64-mingw\bin> [System.Environment]::SetEnvironmentVariable('CURL_SSL_BACKEND','',[System.EnvironmentVariableTarget]::Process)
> PS C:\Users\ckruegeradi\curl-7.84.0_9-win64-mingw\bin> .\curl.exe -ivhttps://tfs.de.kworld.kpmg.com -debug
> * Trying 10.145.235.171:443...
> * Connected to tfs.de.kworld.kpmg.com (10.145.235.171) port 443 (#0)
> * ALPN: offers h2
> * ALPN: offers http/1.1
> * TLSv1.0 (OUT), TLS header, Certificate Status (22):
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * TLSv1.2 (IN), TLS header, Certificate Status (22):
> * TLSv1.3 (IN), TLS handshake, Server hello (2):
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> * TLSv1.2 (OUT), TLS header, Unknown (21):
> * TLSv1.2 (OUT), TLS alert, unknown CA (560):
> * SSL certificate problem: unable to get local issuer certificate
> * Closing connection 0
> curl: (60) SSL certificate problem: unable to get local issuer certificate
> More details here:https://curl.se/docs/sslcerts.html
>
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.
>
> ----
> I export the root CA certificate
>
> $header="-----BEGIN CERTIFICATE-----`n"
> $footer="`n-----END CERTIFICATE-----`n"
> $kpmgrootcerts=Get-Childitem -Path Cert:\LocalMachine\root | where {$_.thumbprint -eq "9F3978578CDA894B03A0E94BA60BCD35BA1090B3"}
>
> $output=''
> foreach ($cert in $kpmgrootcerts)
> {
> $formattedcert=$header
> $formattedcert+=[convert]::tobase64string($cert.RawData) -replace ".{64}" , "$&`n"
> $formattedcert+=$footer
> $formattedcert=$formattedcert -replace "(`r?`n){2}","`n"
> $output+=$formattedcert
> }
>
> $output | Out-File -FilePath 'C:\Users\ckruegeradi\curl-7.84.0_9-win64-mingw\bin\curl-ca-bundle.crt' -Append -Encoding ascii -NoNewline
>
> ----
>
> Now curl with openssl backend is working
>
> It makes no sense for me that curl with SChannel backend is telling me that the authority is not trusted.
> It's the same authority that is working for IE and Invoke-Webrequest and the same that is working for OpenSSL if I export it.
>
> Do you have any ideas how to debug this?
>
> ----
>
> PS C:\Users\ckruegeradi\curl-7.84.0_9-win64-mingw\bin>
> PS C:\Users\ckruegeradi\curl-7.84.0_9-win64-mingw\bin> .\curl.exe -ivhttps://tfs.de.kworld.kpmg.com -debug
> * Trying 10.145.235.171:443...
> * Connected to tfs.de.kworld.kpmg.com (10.145.235.171) port 443 (#0)
> * ALPN: offers h2
> * ALPN: offers http/1.1
> * CAfile: C:\Users\ckruegeradi\curl-7.84.0_9-win64-mingw\bin\curl-ca-bundle.crt
> * CApath: none
> * TLSv1.0 (OUT), TLS header, Certificate Status (22):
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * TLSv1.2 (IN), TLS header, Certificate Status (22):
> * TLSv1.3 (IN), TLS handshake, Server hello (2):
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
> * TLSv1.2 (IN), TLS handshake, Server finished (14):
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
> * TLSv1.2 (OUT), TLS header, Finished (20):
> * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
> * TLSv1.2 (OUT), TLS handshake, Finished (20):
> * TLSv1.2 (IN), TLS header, Finished (20):
> * TLSv1.2 (IN), TLS header, Certificate Status (22):
> * TLSv1.2 (IN), TLS handshake, Finished (20):
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
> * ALPN: server accepted h2
> * Server certificate:
> * subject: C=DE; ST=Germany; L=Berlin; O=KPMG; OU=KPMG ITS; CN=defr2app274.de.kworld.kpmg.com
> * start date: Apr 1 06:10:07 2021 GMT
> * expire date: Apr 1 06:10:07 2023 GMT
> * subjectAltName: host "tfs.de.kworld.kpmg.com" matched cert's "tfs.de.kworld.kpmg.com"
> * issuer: C=GO; ST=England; L=London; O=KPMG Internal Certificate Services; OU=KPMG High Assurance CA; CN=KPMG Internal Issuing CA GO06;emailAddress=go-fmitsglobalcertif_at_kpmg.com
> * SSL certificate verify ok.
> * Using HTTP2, server supports multiplexing
> * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
> * h2h3 [:method: POST]
> * h2h3 [:path: /]
> * h2h3 [:scheme: https]
> * h2h3 [:authority: tfs.de.kworld.kpmg.com]
> * h2h3 [user-agent: curl/7.84.0]
> * h2h3 [accept: */*]
> * h2h3 [content-length: 4]
> * h2h3 [content-type: application/x-www-form-urlencoded]
> * Using Stream ID: 1 (easy handle 0x1934bd4f320)
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
>> POST / HTTP/2
>> Host: tfs.de.kworld.kpmg.com
>> user-agent: curl/7.84.0
>> accept: */*
>> content-length: 4
>> content-type: application/x-www-form-urlencoded
>>
> * TLSv1.2 (IN), TLS header, Supplemental data (23):
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
> * We are completely uploaded and fine
> * TLSv1.2 (IN), TLS header, Supplemental data (23):
> * TLSv1.2 (IN), TLS header, Supplemental data (23):
> < HTTP/2 401
> HTTP/2 401


curl -debug switch is not valid, it is interpreted as -d ebug. Users are
allowed to eschew the space for a short option when a value follows.
Short options use a single dash followed by a single alphanumeric like
-v, and long options use a double dash followed by the word like --verbose.

SEC_E_UNTRUSTED_ROOT usually means the root certificate is not in the
root store. After I added "KPMG Internal Root CA"
(9f3978578cda894b03a0e94ba60bcd35ba1090b3, same thumbprint) to my root
store the transfer was successful, so I think it is interesting that you
do not see the same result. Do you see the certificate in "Trusted Root
Certification Authorities", are there multiple certificates with that
name, and do any of them have that thumbprint?

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

Received on 2022-08-29