root#XXXXXX:/var/tmp# curl --tlsv1.2 --tls-max 1.2 -v
https://example.com:8443/health --cacert Internal_Root_CA.cer
Trying 10.50.65.56...
TCP_NODELAY set
Connected to example.com (10.50.65.56) port 8443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: Internal_Root_CA.cer CApath: /etc/ssl/certs
TLSv1.2 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (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 handshake, Client key exchange (16):
TLSv1.2 (OUT), TLS change cipher, Client hello (1):
TLSv1.2 (OUT), TLS handshake, Finished (20):
TLSv1.2 (IN), TLS handshake, Finished (20):
SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
ALPN, server did not agree to a protocol
Server certificate:
subject: C=US; ST=ZZZ; L=CCC; O=Company; CN=example.com
start date: Sep 29 22:30:19 2022 GMT
expire date: Sep 27 22:30:49 2024 GMT
subjectAltName: host "example.com" matched cert's "example.com"
issuer: O=Company; CN= Issuing CA
SSL certificate verify ok.
GET /health HTTP/1.1
Host: example.com:8443
User-Agent: curl/7.58.0
Accept: /
< HTTP/1.1 200 < Content-Type: text/plain;charset=UTF-8 < Content-Length: 0 < Date: Wed, 12 Oct 2022 18:33:10 GMT <
Connection #0 to host mdm-dev.gcp.aexp.com left intact
Am I using 1 way or 2 way SSL? THe REST API is developed using Spring boot.
I have to pass in the Root CA for the Call to work.
This is 1-way SSL because a) you don't give a client certificate to use and b) the server does not even request one (no CertificateRequest message from server).
Related
I have an api called api-gateway-v1.
this api is a http_proxy.
The method_request authorization is set to NONE.
The method_execution is set to passthrough.
There are two custom domain names which call the same api (same stage).
custom-domain-name-1 has no mutual_tls works as expected.
custom-domain-name-2 has mutual_tls works as expected.
custom domain-1 curl verbose o/p:
curl -v --location --request POST 'https://custom-domain-name-1/v1' --header 'Content-Type: application/json' --data-raw {"email":"email#example.com","password":"mypassword"}'
TCP_NODELAY set
Connected to custom-domain-name-1 (1.2.3.5) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
TLSv1.3 (OUT), TLS handshake, Client hello (1):
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 handshake, Client key exchange (16):
TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.2 (OUT), TLS handshake, Finished (20):
TLSv1.2 (IN), TLS handshake, Finished (20):
SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
ALPN, server accepted to use h2
Server certificate:
subject: CN=custom-domain-name-1
start date: Mar 1 00:00:00 2021 GMT
expire date: Mar 30 23:59:59 2022 GMT
subjectAltName: host "custom-domain-name-1" matched cert's "custom-domain-name-1"
issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
SSL certificate verify ok.
Using HTTP2, server supports multi-use
Connection state changed (HTTP/2 confirmed)
Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
Using Stream ID: 1 (easy handle 0x55c4d244ae10)
POST /v1 HTTP/2
Host: custom-domain-name-1
user-agent: curl/7.68.0
accept: */*
content-type: application/json
content-length: 76
Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
We are completely uploaded and fine
HTTP/2 200
date: Tue, 10 Aug 2021 07:56:41 GMT
content-type: application/json
content-length: 1009
x-amzn-requestid: 8997bed9-b2d5-48fe-8cf2-0d9166ec489d
x-amzn-remapped-connection: keep-alive
x-ratelimit-remaining: 999
x-amz-apigw-id: abc=
cache-control: private, must-revalidate
x-amzn-remapped-server: nginx
x-ratelimit-limit: 1000
x-content-type-options: nosniff
expires: -1
pragma: no-cache
x-amzn-remapped-date: Tue, 10 Aug 2021 07:56:41 GMT
Connection #0 to host custom-domain-name-1 left intact
{"success":{"token":"XYZ"}}
custom domain-2 curl verbose o/p:
curl -v --key form.key --cert cert.pem https://custom-domain-name-2/v1 --header 'Content-Type: application/json' --data-raw '{"email":"email#example.com","password":"mypassword"}'
Note: Unnecessary use of -X or --request, POST is already inferred.
Trying 54.251.193.98:443...
TCP_NODELAY set
Connected to custom-domain-name-2 (1.2.3.4) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
TLSv1.3 (OUT), TLS handshake, Client hello (1):
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, Request CERT (13):
TLSv1.2 (IN), TLS handshake, Server finished (14):
TLSv1.2 (OUT), TLS handshake, Certificate (11):
TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
TLSv1.2 (OUT), TLS handshake, CERT verify (15):
TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.2 (OUT), TLS handshake, Finished (20):
TLSv1.2 (IN), TLS handshake, Finished (20):
SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
ALPN, server accepted to use h2
Server certificate:
subject: CN=custom-domain-name-2
start date: Aug 5 00:00:00 2021 GMT
expire date: Sep 3 23:59:59 2022 GMT
subjectAltName: host "custom-domain-name-2" matched cert's "custom-domain-name-2"
issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
SSL certificate verify ok.
Using HTTP2, server supports multi-use
Connection state changed (HTTP/2 confirmed)
Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
Using Stream ID: 1 (easy handle 0x555588810e10)
POST /v1 HTTP/2
Host: custom-domain-name-2
user-agent: curl/7.68.0
accept: */*
content-type: application/json
content-length: 66
We are completely uploaded and fine
Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
HTTP/2 403
x-amzn-requestid: abc-123
x-amzn-errortype: MissingAuthenticationTokenException
x-amz-apigw-id: 123-abc
content-type: application/json
content-length: 42
date: Wed, 11 Aug 2021 10:53:59 GMT
Connection #0 to host custom-domain-name-2 left intact {"message":"Missing Authentication Token"}
The connection seems to be fine but the HTTP code is changing.
Does anyone has insight into what's happening?
I solved it by Enabling CORS which was missing.
I have deployed an AWS S3 compatible solution on which I configured signed certificates for the API endpoint.
Now, if I try to list some buckets, I get:
$ aws s3 ls s3://bucket --endpoint-url https://s3.endpoint --ca-bundle /etc/ssl/certs/ca-certificates.crt
SSL validation failed for https://s3.endpoint/bucket?list-type=2&prefix=&delimiter=%2F&encoding-type=url
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get issuer certificate (_ssl.c:1125)
But if I curl the same S3 endpoint from the same machine, I get SSL certificate verify ok:
curl https://s3.endpoint -v
* Trying 192.168.0.1:443...
* TCP_NODELAY set
* Connected to s3.endpoint (192.168.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* 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 handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=my-C; ST=my-ST; L=my-L; O=my-O; OU=my-OU; CN=s3.endpoint; emailAddress=my-email
* start date: Jun 28 11:03:53 2021 GMT
* expire date: Jun 28 11:03:53 2023 GMT
* subjectAltName: host "s3.endpoint" matched cert's "s3.endpoint"
* issuer: C=issuer-C; O=issuer-O; OU=issuer-OU; CN=issuer-CN
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: s3.endpoint
> User-Agent: curl/7.68.0
> Accept: */*
>
...
Is there something wrong with my aws command ?
$ aws --version
aws-cli/2.2.14 Python/3.8.8 Linux/5.4.0-73-generic exe/x86_64.ubuntu.20 prompt/off
about to bash my head against the wall after trying to sort this for over a week so really hoping someone can shed some light on where I've gone wrong with nginx!
I have this nginx.conf file which works perfectly (the way I want anyway)
events {
worker_connections 4096;
}
stream {
upstream stream_backend {
server backendapp:80;
}
server {
listen 443 ssl;
listen 8080;
proxy_pass stream_backend;
ssl_certificate ssl.crt;
ssl_certificate_key ssl.key;
ssl_protocols SSLv3 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 4h;
ssl_handshake_timeout 30s;
#ssl_client_certificate ca.crt;
#ssl_verify_client on;
error_log /var/log/nginx/error.log debug;
}
}
However, I've been asked to enable client certificate, and when I remove the comments from #ssl_client_certificate ca.crt; and #ssl_verify_client on; I get these error logged in nginx *13 client sent no required SSL certificate while SSL handshaking, client: 192.168.65.3, server: 0.0.0.0:443
This is despite me sending client certs as part of the request.
I've scoured the internet and have found various solutions but none have worked for me so far (including here at SO). Any help would be greatly appreciated.
I'm using curl like so
curl -v -k C:\Temp\opscert\user.key -cert C:\Temp\opscert\user.crt https://local.example.com
and
curl -vk --key C:\Temp\opscert\user.key -cert C:\Temp\opscert\user.crt https://local.example.com
also with powershell for good measure
Invoke-WebRequest https://local.example.com -CertificateThumbprint 3b23775c0abfa0e9cb43e87b206dd6992ffc7e07
Additionally, I would have expected browsers to prompt for a certificate when browsing to https://local.example.com/ but none do, I've tried on firefox, IE and Chrome.
The only time chrome did request a certificate once is when I changed ssl_verify_client on; to ssl_verify_client optional; however this is not what we want.
Here are the errors from nginx
2018/11/23 17:21:42 [info] 6#6: *21 client 192.168.65.3:58176 connected to 0.0.0.0:443
2018/11/23 17:21:42 [info] 6#6: *21 client sent no required SSL certificate while SSL handshaking, client: 192.168.65.3, server: 0.0.0.0:443
2018/11/23 17:21:43 [info] 6#6: *22 client 192.168.65.3:58178 connected to 0.0.0.0:443
2018/11/23 17:21:43 [info] 6#6: *22 client sent no required SSL certificate while SSL handshaking, client: 192.168.65.3, server: 0.0.0.0:443
2018/11/23 17:21:48 [info] 6#6: *23 client 192.168.65.3:58194 connected to 0.0.0.0:443
2018/11/23 17:21:48 [info] 6#6: *23 client sent no required SSL certificate while SSL handshaking, client: 192.168.65.3, server: 0.0.0.0:443
2018/11/23 17:22:18 [info] 6#6: *24 client 192.168.65.3:58256 connected to 0.0.0.0:443
2018/11/23 17:22:18 [info] 6#6: *24 client sent no required SSL certificate while SSL handshaking, client: 192.168.65.3, server: 0.0.0.0:443
2018/11/23 17:23:18 [info] 6#6: *25 client 192.168.65.3:58378 connected to 0.0.0.0:443
2018/11/23 17:23:18 [info] 6#6: *25 client sent no required SSL certificate while SSL handshaking, client: 192.168.65.3, server: 0.0.0.0:443
Response from curl
PS C:\Users\abx> curl -v -k C:\Temp\opscert\user.key -cert C:\Temp\opscert\user.crt https://client.example.com
* Rebuilt URL to: C:\Temp\opscert\user.key/
* Port number ended with '\'
* Closing connection -1
curl: (3) Port number ended with '\'
* Rebuilt URL to: C:\Temp\opscert\user.crt/
* Port number ended with '\'
* Closing connection -1
curl: (3) Port number ended with '\'
* Rebuilt URL to: https://client.example.com/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to client.example.com (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=GB; ST=Surrey; L=London; O=H. Example Company Ltd; CN=*.example.com
* start date: Jan 5 00:00:00 2017 GMT
* expire date: Jan 10 12:00:00 2020 GMT
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: client.example.com
> User-Agent: curl/7.59.0
> Accept: */*
>
* TLSv1.2 (IN), TLS alert, Client hello (1):
* Empty reply from server
* Connection #0 to host client.example.com left intact
curl: (52) Empty reply from server
PS C:\Users\abx> curl -vk --key C:\Temp\opscert\user.key -cert C:\Temp\opscert\user.crt https://local.example.com
* Rebuilt URL to: C:\Temp\opscert\user.crt/
* Port number ended with '\'
* Closing connection -1
curl: (3) Port number ended with '\'
* Rebuilt URL to: https://local.example.com/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to client.example.com (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=GB; ST=Surrey; L=London; O=H. Example Company Ltd; CN=*.example.com
* start date: Jan 5 00:00:00 2017 GMT
* expire date: Jan 10 12:00:00 2020 GMT
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: client.example.com
> User-Agent: curl/7.59.0
> Accept: */*
>
* TLSv1.2 (IN), TLS alert, Client hello (1):
* Empty reply from server
* Connection #0 to host client.example.com left intact
curl: (52) Empty reply from server
for powershell import just the user.crt (not pfx)
for curl, same thing, use user.crt curl -v --key C:\Temp\opscert\user.key --cert C:\Temp\opscert\user.crt https://client.example.com
I'd still prefer if when accessing via a browser I was prompted to for cert working but for now this is perfect as the requests will come from an api.
Currently I'm testing web-application on IIS 10 using HTTP 1.1 and HTTP/2.
My test application has one endpoint (/api/test) which returns just 'true'.
I have 3 certificates:
Root CA (self-signed)
Server certificate signed by Root CA
Client certificate signed by Root CA
Root CA and Server certificate installed on Windows Server 2016, and IIS website configured for listen https://example.net:8081/ using Server certificate. Also I configure website to require client certificate (it is important for my tests, I need server/client certificates validation).
I test my app via curl, and for http1.1 all works fine.
Command:
curl.exe --http1.1 --get --url https://example.net:8081/api/test --cacert E:\ca.pem --cert E:\client.pem --key E:\client.key --cert-type PEM --verbose
Output:
* TCP_NODELAY set
* Connected to example.net port 8081 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: E:\ca.pem
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* 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 handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate: XXX
* SSL certificate verify ok.
> GET /api/test HTTP/1.1
> Host: example.net:8081
> User-Agent: curl/7.61.1
> Accept: */*
>
* TLSv1.2 (IN), TLS handshake, Hello request (0):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Content-Type: application/json; charset=utf-8
< Server: Kestrel
< Date: Tue, 18 Sep 2018 13:45:35 GMT
<
true* Connection #0 to host abrakadabra.cranecs.net left intact
But if I try to send request using http/2, it is failed after server certificate validation.
Command:
curl.exe --http2 --get --url https://example.net:8081/api/test --cacert E:\ca.pem --cert E:\client.pem --key E:\client.key --cert-type PEM --verbose
Output:
* TCP_NODELAY set
* Connected to example.net port 8081 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: E:\ca.pem
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* 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 handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate: XXX
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x1f635299100)
> GET /api/test HTTP/2
> Host: example.net:8081
> User-Agent: curl/7.61.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* HTTP/2 stream 0 was not closed cleanly: HTTP_1_1_REQUIRED (err 13)
* stopped the pause stream!
* Connection #0 to host example.net left intact
curl: (92) HTTP/2 stream 0 was not closed cleanly: HTTP_1_1_REQUIRED (err 13)
In IIS logs I see next records:
2018-09-18 13:46:00 172.32.0.193 GET /api/test - 8081 - 134.17.25.89 HTTP/1.1 curl/7.61.1 - 200 0 0 421
2018-09-18 13:55:01 172.32.0.193 GET /api/test - 8081 - 134.17.25.89 HTTP/2.0 curl/7.61.1 - 403 7 64 0
So, for http/2 it seems like client certificate absent (403.7 status code).
And finally, if I'll just change 'require client certificate' to 'ignore client certificate' on IIS site settings - http1.1 and http/2 work both.
How can I use client certificate with HTTP/2 on IIS?
After couple hours of research, I find out that the IIS 10 currently doesn't support HTTP/2 with client certificate verification.
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-not-supported
In a few cases, HTTP/2 can't be used in combination with other features. In these situations, Windows will fall back to HTTP/1.1 and continue the transaction. This may involve negotiating HTTP/1.1 during the handshake, or sending an error code to the client instructing it to retry over an HTTP/1.1 connection.
I was reconfigure my server to use nginx instead of IIS as a proxy for app, and all works fine.
I also stumbled upon this issue and after reading this information, I discovered that you need to enable "Negotiate Client Certificate" ath the binding level.
I set up a DotNet Framework 4.8 website in Server 2022 with IIS 10 and turned on require client certificates. IE worked with this fine. TLS1.3 enabled browsers did not (tried Edge and Chrome). A Wireshark capture showed the connection being reset during the handshake. After playing with editing the website bindings, I found in order for it to work, I could either enable TLS 1.3 or HTTP/2, but not both, when requiring client certificates and using a TLS1.3 enabled client.
Hopefully Microsoft will fix this for us someday
The context is i created a WCF Service, hosted in IIS using https.
I have no issues with the WCF Service itself, it is working as it should; I can navigate to the service page at
https://myhost/VirtualAppOnIIS/Some/WCF/Service/Here/V1
using a Browser (IE in my case).
The "lock" symbol displays ok, and i can view the certificate info; More cert info is:
root CA is Verisign, which issued a Verisign Intermediate cert, which issued
my server cert (let's call it "myhost")
"Key Usage" set as critical, purposes are: Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment (f0)
The "Extended Key Usage" is absent, so i can conclude it is undefined / not set by the certificate issuer (and therefore this cert can be used as both Server cert or Client cert)
So far so good. My real issue is how to get curl to make a /GET https request (similar to the way the Browser does it).
Attempt #1.
curl --tlsv1.2 https://myhost/VirtualAppOnIIS/Some/WCF/Service/Here/V1 -v
* Trying 192.168.1.114...
* TCP_NODELAY set
* Connected to myhost (192.168.1.114) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: C:\SETUPS\curl\curl-ca-bundle.crt CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unsupported certificate purpose
* stopped the pause stream!
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1): curl: (60) SSL certificate problem: unsupported certificate purpose
More details here: https://curl.haxx.se/docs/sslcerts.html
...etc ...
If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
We can see an error after server hello (2):
SSL certificate problem: unsupported certificate purpose
I made sure I have both certificates for Intermediate and Root CA concatenated within the file curl-ca-bundle.crt (and nothing else), which curl finds by default, and i don't believe it's a chain validation issue, seems a cert purpose problem as suggested by the error message.
Attempt #2
Bybass https validation, as suggested by the curl output, using the -k switch. Yes, it works !
curl --tlsv1.2 https://myhost/VirtualAppOnIIS/Some/WCF/Service/Here/V1 -v -k
* 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 handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=country; ST=state; O=Some Company PTY LIMITED; CN=myhost
* start date: Apr 26 00:00:00 2017 GMT
* expire date: Mar 29 23:59:59 2019 GMT
* issuer: O=VeriSign; OU=Whatever PKI; CN=Whatever Intermediate CA
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
GET /VirtualAppOnIIS/Some/WCF/Service/Here/V1 HTTP/1.1
Host: myhost
User-Agent: curl/7.53.1
Accept: */*
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/8.5
Set-Cookie: ASP.NET_SessionId=iy1s4q1hwkncywi5m0w0coch; path=/; HttpOnly
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 02 May 2018 07:08:30 GMT
Content-Length: 3236
<HTML><HEAD>
etc... etc... more html for wcf service page... etc ... etc...
</BODY></HTML>
Connection #0 to host myhost left intact
So to re-phrase the question, if it is a cert. purpose issue (as suggested in attempt #1), what cert. purposes or settings or configurations are required (when issuing the cert) to make curl and WCF with TLS work ?
Incidentally i am using curl on Windows from https://winampplugins.co.uk/curl/