nginx client sent no required SSL certificate while SSL handshaking
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
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:Tempopscertuser.key -cert C:Tempopscertuser.crt https://local.example.com
and
curl -vk --key C:Tempopscertuser.key -cert C:Tempopscertuser.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:Usersabx> curl -v -k C:Tempopscertuser.key -cert C:Tempopscertuser.crt https://client.example.com
* Rebuilt URL to: C:Tempopscertuser.key/
* Port number ended with ''
* Closing connection -1
curl: (3) Port number ended with ''
* Rebuilt URL to: C:Tempopscertuser.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:Usersabx> curl -vk --key C:Tempopscertuser.key -cert C:Tempopscertuser.crt https://local.example.com
* Rebuilt URL to: C:Tempopscertuser.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
ssl
|
show 6 more comments
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:Tempopscertuser.key -cert C:Tempopscertuser.crt https://local.example.com
and
curl -vk --key C:Tempopscertuser.key -cert C:Tempopscertuser.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:Usersabx> curl -v -k C:Tempopscertuser.key -cert C:Tempopscertuser.crt https://client.example.com
* Rebuilt URL to: C:Tempopscertuser.key/
* Port number ended with ''
* Closing connection -1
curl: (3) Port number ended with ''
* Rebuilt URL to: C:Tempopscertuser.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:Usersabx> curl -vk --key C:Tempopscertuser.key -cert C:Tempopscertuser.crt https://local.example.com
* Rebuilt URL to: C:Tempopscertuser.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
ssl
"..This is despite me sending client certs as part of the request..." - likely you don't. Please show how your client sends the client cert as you claim. The configuration of the server side only shows that the server requests a client certificate but not that the client actually sends one.
– Steffen Ullrich
Nov 23 '18 at 16:37
-k(as shown in the question and at first in the comment) is not the option for curl to specify the private key but to ignore certificate errors but--keyis (as shown second). Given that the problem is the client likely not sending the command it does not help a lot to show the server side errors only and especially not the same error 6 times. Please include the verbose output (-v) of the correct curl command into your question-
– Steffen Ullrich
Nov 23 '18 at 17:36
Thanks for your response. The problem is not just with curl, I've tried with powershell and with 3 different browsers with all showing the same error in server which is the reason behind same error showing 6 times. Will get a verbose log output for curl but as I said this isn't restricted to just curl.
– Abu Belal
Nov 23 '18 at 17:56
Maybe its not restricted to curl but curl usually provides verbose output usable to debug such a problem while the others don't.
– Steffen Ullrich
Nov 23 '18 at 18:17
1
The options should be--keyand--cert, not-k(first try) and-cert(both tries). This way you effectively don't properly specify a certificate and that's why none will be send. But one can see that the server is requesting a certificate from the client and the client is sending a (likely empty since none was properly specified) certificate in the handshake, so the server part seems to work.
– Steffen Ullrich
Nov 23 '18 at 19:52
|
show 6 more comments
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:Tempopscertuser.key -cert C:Tempopscertuser.crt https://local.example.com
and
curl -vk --key C:Tempopscertuser.key -cert C:Tempopscertuser.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:Usersabx> curl -v -k C:Tempopscertuser.key -cert C:Tempopscertuser.crt https://client.example.com
* Rebuilt URL to: C:Tempopscertuser.key/
* Port number ended with ''
* Closing connection -1
curl: (3) Port number ended with ''
* Rebuilt URL to: C:Tempopscertuser.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:Usersabx> curl -vk --key C:Tempopscertuser.key -cert C:Tempopscertuser.crt https://local.example.com
* Rebuilt URL to: C:Tempopscertuser.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
ssl
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:Tempopscertuser.key -cert C:Tempopscertuser.crt https://local.example.com
and
curl -vk --key C:Tempopscertuser.key -cert C:Tempopscertuser.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:Usersabx> curl -v -k C:Tempopscertuser.key -cert C:Tempopscertuser.crt https://client.example.com
* Rebuilt URL to: C:Tempopscertuser.key/
* Port number ended with ''
* Closing connection -1
curl: (3) Port number ended with ''
* Rebuilt URL to: C:Tempopscertuser.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:Usersabx> curl -vk --key C:Tempopscertuser.key -cert C:Tempopscertuser.crt https://local.example.com
* Rebuilt URL to: C:Tempopscertuser.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
ssl
ssl
edited Nov 23 '18 at 19:47
Abu Belal
asked Nov 23 '18 at 12:41
Abu BelalAbu Belal
444
444
"..This is despite me sending client certs as part of the request..." - likely you don't. Please show how your client sends the client cert as you claim. The configuration of the server side only shows that the server requests a client certificate but not that the client actually sends one.
– Steffen Ullrich
Nov 23 '18 at 16:37
-k(as shown in the question and at first in the comment) is not the option for curl to specify the private key but to ignore certificate errors but--keyis (as shown second). Given that the problem is the client likely not sending the command it does not help a lot to show the server side errors only and especially not the same error 6 times. Please include the verbose output (-v) of the correct curl command into your question-
– Steffen Ullrich
Nov 23 '18 at 17:36
Thanks for your response. The problem is not just with curl, I've tried with powershell and with 3 different browsers with all showing the same error in server which is the reason behind same error showing 6 times. Will get a verbose log output for curl but as I said this isn't restricted to just curl.
– Abu Belal
Nov 23 '18 at 17:56
Maybe its not restricted to curl but curl usually provides verbose output usable to debug such a problem while the others don't.
– Steffen Ullrich
Nov 23 '18 at 18:17
1
The options should be--keyand--cert, not-k(first try) and-cert(both tries). This way you effectively don't properly specify a certificate and that's why none will be send. But one can see that the server is requesting a certificate from the client and the client is sending a (likely empty since none was properly specified) certificate in the handshake, so the server part seems to work.
– Steffen Ullrich
Nov 23 '18 at 19:52
|
show 6 more comments
"..This is despite me sending client certs as part of the request..." - likely you don't. Please show how your client sends the client cert as you claim. The configuration of the server side only shows that the server requests a client certificate but not that the client actually sends one.
– Steffen Ullrich
Nov 23 '18 at 16:37
-k(as shown in the question and at first in the comment) is not the option for curl to specify the private key but to ignore certificate errors but--keyis (as shown second). Given that the problem is the client likely not sending the command it does not help a lot to show the server side errors only and especially not the same error 6 times. Please include the verbose output (-v) of the correct curl command into your question-
– Steffen Ullrich
Nov 23 '18 at 17:36
Thanks for your response. The problem is not just with curl, I've tried with powershell and with 3 different browsers with all showing the same error in server which is the reason behind same error showing 6 times. Will get a verbose log output for curl but as I said this isn't restricted to just curl.
– Abu Belal
Nov 23 '18 at 17:56
Maybe its not restricted to curl but curl usually provides verbose output usable to debug such a problem while the others don't.
– Steffen Ullrich
Nov 23 '18 at 18:17
1
The options should be--keyand--cert, not-k(first try) and-cert(both tries). This way you effectively don't properly specify a certificate and that's why none will be send. But one can see that the server is requesting a certificate from the client and the client is sending a (likely empty since none was properly specified) certificate in the handshake, so the server part seems to work.
– Steffen Ullrich
Nov 23 '18 at 19:52
"..This is despite me sending client certs as part of the request..." - likely you don't. Please show how your client sends the client cert as you claim. The configuration of the server side only shows that the server requests a client certificate but not that the client actually sends one.
– Steffen Ullrich
Nov 23 '18 at 16:37
"..This is despite me sending client certs as part of the request..." - likely you don't. Please show how your client sends the client cert as you claim. The configuration of the server side only shows that the server requests a client certificate but not that the client actually sends one.
– Steffen Ullrich
Nov 23 '18 at 16:37
-k (as shown in the question and at first in the comment) is not the option for curl to specify the private key but to ignore certificate errors but --key is (as shown second). Given that the problem is the client likely not sending the command it does not help a lot to show the server side errors only and especially not the same error 6 times. Please include the verbose output (-v) of the correct curl command into your question-– Steffen Ullrich
Nov 23 '18 at 17:36
-k (as shown in the question and at first in the comment) is not the option for curl to specify the private key but to ignore certificate errors but --key is (as shown second). Given that the problem is the client likely not sending the command it does not help a lot to show the server side errors only and especially not the same error 6 times. Please include the verbose output (-v) of the correct curl command into your question-– Steffen Ullrich
Nov 23 '18 at 17:36
Thanks for your response. The problem is not just with curl, I've tried with powershell and with 3 different browsers with all showing the same error in server which is the reason behind same error showing 6 times. Will get a verbose log output for curl but as I said this isn't restricted to just curl.
– Abu Belal
Nov 23 '18 at 17:56
Thanks for your response. The problem is not just with curl, I've tried with powershell and with 3 different browsers with all showing the same error in server which is the reason behind same error showing 6 times. Will get a verbose log output for curl but as I said this isn't restricted to just curl.
– Abu Belal
Nov 23 '18 at 17:56
Maybe its not restricted to curl but curl usually provides verbose output usable to debug such a problem while the others don't.
– Steffen Ullrich
Nov 23 '18 at 18:17
Maybe its not restricted to curl but curl usually provides verbose output usable to debug such a problem while the others don't.
– Steffen Ullrich
Nov 23 '18 at 18:17
1
1
The options should be
--key and --cert, not -k (first try) and -cert (both tries). This way you effectively don't properly specify a certificate and that's why none will be send. But one can see that the server is requesting a certificate from the client and the client is sending a (likely empty since none was properly specified) certificate in the handshake, so the server part seems to work.– Steffen Ullrich
Nov 23 '18 at 19:52
The options should be
--key and --cert, not -k (first try) and -cert (both tries). This way you effectively don't properly specify a certificate and that's why none will be send. But one can see that the server is requesting a certificate from the client and the client is sending a (likely empty since none was properly specified) certificate in the handshake, so the server part seems to work.– Steffen Ullrich
Nov 23 '18 at 19:52
|
show 6 more comments
1 Answer
1
active
oldest
votes
for powershell import just the user.crt (not pfx)
for curl, same thing, use user.crt curl -v --key C:Tempopscertuser.key --cert C:Tempopscertuser.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.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53446913%2fnginx-client-sent-no-required-ssl-certificate-while-ssl-handshaking%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
for powershell import just the user.crt (not pfx)
for curl, same thing, use user.crt curl -v --key C:Tempopscertuser.key --cert C:Tempopscertuser.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.
add a comment |
for powershell import just the user.crt (not pfx)
for curl, same thing, use user.crt curl -v --key C:Tempopscertuser.key --cert C:Tempopscertuser.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.
add a comment |
for powershell import just the user.crt (not pfx)
for curl, same thing, use user.crt curl -v --key C:Tempopscertuser.key --cert C:Tempopscertuser.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.
for powershell import just the user.crt (not pfx)
for curl, same thing, use user.crt curl -v --key C:Tempopscertuser.key --cert C:Tempopscertuser.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.
answered Nov 24 '18 at 21:06
Abu BelalAbu Belal
444
444
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53446913%2fnginx-client-sent-no-required-ssl-certificate-while-ssl-handshaking%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
"..This is despite me sending client certs as part of the request..." - likely you don't. Please show how your client sends the client cert as you claim. The configuration of the server side only shows that the server requests a client certificate but not that the client actually sends one.
– Steffen Ullrich
Nov 23 '18 at 16:37
-k(as shown in the question and at first in the comment) is not the option for curl to specify the private key but to ignore certificate errors but--keyis (as shown second). Given that the problem is the client likely not sending the command it does not help a lot to show the server side errors only and especially not the same error 6 times. Please include the verbose output (-v) of the correct curl command into your question-– Steffen Ullrich
Nov 23 '18 at 17:36
Thanks for your response. The problem is not just with curl, I've tried with powershell and with 3 different browsers with all showing the same error in server which is the reason behind same error showing 6 times. Will get a verbose log output for curl but as I said this isn't restricted to just curl.
– Abu Belal
Nov 23 '18 at 17:56
Maybe its not restricted to curl but curl usually provides verbose output usable to debug such a problem while the others don't.
– Steffen Ullrich
Nov 23 '18 at 18:17
1
The options should be
--keyand--cert, not-k(first try) and-cert(both tries). This way you effectively don't properly specify a certificate and that's why none will be send. But one can see that the server is requesting a certificate from the client and the client is sending a (likely empty since none was properly specified) certificate in the handshake, so the server part seems to work.– Steffen Ullrich
Nov 23 '18 at 19:52