I'm testing SSL Insecure Renegotiation vulnerability with Apache and OpenSSL.
When Apache 2.2.14 was compiled against OpenSSL 0.9.8k, openssl command could establish client-initiated insecure SSL renegotiation with Apache as follows:
# /usr/local/openssl-0.9.8k/bin/openssl s_client -connect debian:443
[...]
HEAD / HTTP/1.0
R
RENEGOTIATING
depth=0 /C=UA/ST=Some-State/O=Alice Cruel Ltd/CN=strawberry.xxx
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=UA/ST=Some-State/O=Alice Cruel Ltd/CN=strawberry.xxx
verify return:1
HTTP/1.1 200 OK
Date: Thu, 23 Jan 2014 13:54:33 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k
Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT
ETag: "1b006b0-2c-3e9564c23b600"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html
closed
#
But with Apache 2.2.15 compiled against OpenSSL 0.9.8m, client-initiated SSL renegotiation failed even when "SSLInsecureRenegotiation on" was added to ssl.conf:
# /usr/local/openssl-0.9.8k/bin/openssl s_client -connect debian:443
CONNECTED(00000003)
[...]
HEAD / HTTP/1.0
R
RENEGOTIATING
4790:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:
#
The latter result is seemingly unexpected. Is SSLInsecureRenegotiation directive not working? I want to know how to make the directive effective.
Thank you in advance.
Related
I just can't manage to get an OCSP response. Here are the steps I did:
Haproxy cert directory:
Added CA file containing root and intermediate CA certificates with .issuer extension.
Added my .pem cert file including private key, crt etc
Generated OCSP response in DER format with openssl:
openssl ocsp -issuer my_cert.issuer -VAfile my_cert.issuer -cert my_cert.pem -url http://status.thawte.com -header Host status.thawte.com -no_nonce -respout my_cert.ocsp
Response verify OK
my_cert.pem: good
This Update: Mar 14 17:45:00 2022 GMT
Next Update: Mar 21 17:00:00 2022 GMT
3 files are now in my HAproxy cert directory:
my_cert.issuer
my_cert.ocsp
my_cert.pem
This is how my HAproxy config looks like:
global
maxconn 4096
ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:RSA+AES128:RC4:HIGH:!MD5:!aNULL:!EDH:!CAMELLIA
log 127.0.0.1 local0 debug
defaults
log global
mode http
option httplog
option dontlognull
option forwardfor
option http-server-close
stats enable
stats uri /stats
timeout connect 3000ms
timeout client 25000ms
timeout server 25000ms
frontend ssl_check
bind :::80
bind :::443 ssl crt /usr/local/etc/haproxy/certs/my_cert.pem
acl https ssl_fc
http-request set-header X-Forwarded-Proto http if !https
http-request set-header X-Forwarded-Proto https if https
mode http
use_backend %[base,lower,map_beg(/usr/local/etc/haproxy/ssl.map)] if { base,lower,map_beg(/usr/local/etc/haproxy/ssl.map) -m found }
default_backend ssl_check
backend ssl_check
mode http
errorfile 503 /usr/local/etc/haproxy/errors/certificate_response.http
This is how my fake backend looks like using a manipulated 503 errorfile giving response 200 back:
HTTP/1.0 200 Found
Cache-Control: no-cache
Connection: close
Content-Type: text/plain
200 Found
Reloaded HAproxy afterwards but I get still the same output:
$ echo quit | openssl s_client -connect 127.0.0.1:443 -tlsextdebug -status
CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "EC point formats" (id=11), len=4
0000 - 03 00 01 02 ....
TLS server extension "session ticket" (id=35), len=0
OCSP response: no response sent
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA 2018
verify return:1
[...]
---
Certificate chain
0 s:/[...]
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=/[...]
issuer=/
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4377 bytes and written 441 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: FDAA738CD5049E2D14F5F7AD1C2CBCA36B938B94755F697E4CE0DCD40342791E
Session-ID-ctx:
Master-Key: [...]
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
[...]
Start Time: 1647360170
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
This is how the HAproxy package is setup regarding to OpenSSL etc:
# haproxy -vv
HA-Proxy version 1.8.19 2019/02/11
Copyright 2000-2019 Willy Tarreau <willy#haproxy.org>
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-null-dereference -Wno-unused-label
OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with OpenSSL version : OpenSSL 1.1.0j 20 Nov 2018
Running on OpenSSL version : OpenSSL 1.1.0j 20 Nov 2018
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.39 2016-06-14
Running on PCRE version : 8.39 2016-06-14
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
Tested it on a docker-compose setup and on a live machine also but in both cased I get ther certificate chain back etc but the OCSP response field is still empty:
OCSP response: no response sent
What am i doing wrong?!
Was able to sort it out. The naming convention of the certificate file name must be followed and was wrong.
Wrong:
my_cert.issuer
my_cert.ocsp
my_cert.pem
Correct:
my_cert.pem.issuer
my_cert.pem.ocsp
my_cert.pem
Then I was able to get an OCSP response from my HAproxy test instance back.
With a slightly older version of curl, I had a handy batch file:
curl --verbose -k https://%1 2>&1 |grep -E "Connected to|subject|expire"
This would show me the IP connected to, with the subject and expiration date of the actual certificate negotiated, even if that was not the correct certificate for that domain name -- which is sometimes a problem for our hosting (we host literally thousands of domains on our multitenant application, about half with their own certs).
In specific, I would see something like this in the stderr output before grep filtered it:
* Server certificate:
* subject: CN=academy-fran.chi.v6.pressero.com
* start date: Feb 22 04:55:00 2017 GMT
* expire date: May 23 04:55:00 2017 GMT
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
Today I had to reinstall the OS on my machine, and reinstalled curl. Now at version 7.52.1 (x86_64-w64-mingw32); previous one seems to have been 7.49.1 (i686-pc-cygwin). Curl no longer displays ANY certificate information, regardless of whether -k is used or not, if the TLS connection succeeds or not.
Is there an option that will give it back to me?
For anyone else on OSX or Linux, you can add this to your ~/.zshrc file:
function seecert () {
nslookup $1
(openssl s_client -showcerts -servername $1 -connect $1:443 <<< "Q" | openssl x509 -text | grep -iA2 "Validity")
}
Example usage, after you have run a source ~/.zshrc after the above additions:
% seecert www.google.com
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.10.100
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
verify return:1
DONE
Validity
Not Before: Nov 3 07:39:18 2020 GMT
Not After : Jan 26 07:39:18 2021 GMT
Thanks go to #ross-presser and his answer for the inspiration for this function.
Here is my replacement batch file, using openssl instead of curl:
#echo off
nslookup %1
(openssl s_client -showcerts -servername %1 -connect %1:443 <nul |openssl x509 -text |findstr /I "DNS After") 2>nul
This gives me this output:
C:\>seecert www.google.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.10.228
Name: www.google.com
Address: 2607:f8b0:4006:813::2004
Not After : Aug 16 09:49:00 2018 GMT
DNS:www.google.com
I am trying to curl a tool's rest api which is using self signed certificate.
curl -D- -u user:pass -X GET -H "Content-Type: application/json" https://server:8006/api2/json/nodes
It gives following error:
"curl: (60) SSL certificate problem: unable to get local issuer certificate"
When using insecure option, following output is received:
HTTP/1.1 401 No ticket
Cache-Control: max-age=0
Connection: close
Date: Mon, 22 Aug 2016 15:25:18 GMT
Pragma: no-cache
Server: pve-api-daemon/3.0
Expires: Mon, 22 Aug 2016 15:25:18 GMT
I tried generating server certificate using:
echo "" | openssl s_client -connect server:8006 -prexit 2>/dev/null | sed -n -e '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p' > cacert.pem
However, when using this certificate using --cacert option it still gives "curl: (60) SSL certificate problem: unable to get local issuer certificate" error message.
Please let me know what am I missing?
A self-signed certificate is untrusted by design, you can't get a self-signed certificate to be trusted.
If you want the certificate to be trusted, you need to purchase/request the certificate from a trusted Certificate Authority.
I've recently changed the IP on a website as I added a SSL certificate.
Now going back to view the site I get the "Apache is working on your cPanel and WHM Server" message.
http://domain.com/cgi-sys/defaultwebpage.cgi
This looks like a cache issue with Chrome as I can see the page on other devices and when using Incognito browsing in Chrome also in other browsers on the same PC.
I've cleared every history entry in Chrome from my domain and also removed cookies. I still can't view my site. It has been 6 days since I changed the IP.
Any ideas? I'd rather be using Chrome by the way .
Thanks for any suggestions :)
The real URL will take you to the site more than likely with no problems www.tshirtsofoz.com.au
It looks like a configuration issue at the server. I don't believe its at the client. Below, the point of interest is the response:
HTTP/1.1 302 Moved Temporarily
Date: Wed, 27 Aug 2014 08:01:52 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
X-Powered-By: PHP/5.4.21
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: https://tshirtsofoz.com.au/xmlrpc.php
Set-Cookie: PHPSESSID=9690b2302154849c9f0f4b1583cd6175; path=/
Location: https://tshirtsofoz.com.au/wp-admin/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
And I get no response when following the redirect (i.e., GET /wp-admin/ ...). If I follow without the trailing slash, I get:
$ echo -e "GET /wp-admin HTTPS/1.1\r\n" | openssl s_client -connect www.tshirtsofoz.com.au:443 -ign_eof
...
HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Aug 2014 08:07:45 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
Location: https://tshirtsofoz.com.au/wp-admin/
Content-Length: 386
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved here.</p>
<hr>
<address>Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4 Server at tshirtsofoz.com.au Port 443</address>
</body></html>
closed
Also, OpenSSL 0.9.8e has a number of vulnerablities.
$ echo -e "GET / HTTPS/1.1\r\n" | openssl s_client -connect www.tshirtsofoz.com.au:443 -ign_eof
CONNECTED(00000003)
depth=1 C = US, ST = Illinois, L = Chicago, O = "Trustwave Holdings, Inc.", CN = "Trustwave Organization Validation CA, Level 2", emailAddress = ca#trustwave.com
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/CN=tshirtsofoz.com.au/O=T-shirts of Oz/L=Adelaide/ST=SA/C=AU
i:/C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Organization Validation CA, Level 2/emailAddress=ca#trustwave.com
1 s:/C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Organization Validation CA, Level 2/emailAddress=ca#trustwave.com
i:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFYTCCBEmgAwIBAgITBlERJ/3dcNwVHxcP+I8iPTg4jTANBgkqhkiG9w0BAQUF
ADCBrjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCElsbGlub2lzMRAwDgYDVQQHEwdD
aGljYWdvMSEwHwYDVQQKExhUcnVzdHdhdmUgSG9sZGluZ3MsIEluYy4xNjA0BgNV
BAMTLVRydXN0d2F2ZSBPcmdhbml6YXRpb24gVmFsaWRhdGlvbiBDQSwgTGV2ZWwg
MjEfMB0GCSqGSIb3DQEJARYQY2FAdHJ1c3R3YXZlLmNvbTAeFw0xNDA4MjExNzM0
MDJaFw0xNTA4MjEyMzM0MDJaMGMxGzAZBgNVBAMMEnRzaGlydHNvZm96LmNvbS5h
dTEXMBUGA1UECgwOVC1zaGlydHMgb2YgT3oxETAPBgNVBAcMCEFkZWxhaWRlMQsw
CQYDVQQIDAJTQTELMAkGA1UEBhMCQVUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQC+9GB9oA1AlmI0BbIqDxpwVwWamGUwfGcc91tHoqkgXDQ/GztGTLb9
OLJD2ZYDt8PWe1NQHlpOo1LZkaqhoUEakvcI0DA10KUYGG77qNGG6jvseue/ndKn
T6UXsptFdnAyDBCbICRcWjcjgPq4MAjkMDCTZSyrQ7fKigjVlAiw0bqh3twnpp+Q
CLk51J3tDto9pYdgUWkEZoL4bdvxdP7iat8cd7b6JQuNWPU28SAagytUNj0IrU1q
nLm8YNJf38QvoWHonXl3dBdrkhHGFE2i7RRirGG6LJHb1KMpmJwXWlX+nHqK2yXk
nBAjsf8pBmSLuLZlPhVzjDGCHbDXS7eTAgMBAAGjggHAMIIBvDALBgNVHQ8EBAMC
BaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMB0GA1UdDgQWBBR+2SN4
zqcGpgpVrM1f36uxdTINBTAfBgNVHSMEGDAWgBRd2ZaaQMcnyyybouzPGavIr8yG
SDBIBgNVHSAEQTA/MD0GDysGAQQBge0YAwMDAwQEAzAqMCgGCCsGAQUFBwIBFhxo
dHRwczovL3NzbC50cnVzdHdhdmUuY29tL0NBMFsGA1UdEQRUMFKCEnRzaGlydHNv
Zm96LmNvbS5hdYIPdHNoaXJ0c29mb3ouY29tghZ3d3cudHNoaXJ0c29mb3ouY29t
LmF1ghN3d3cudHNoaXJ0c29mb3ouY29tMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6
Ly9jcmwudHJ1c3R3YXZlLmNvbS9PVkNBX0wyLmNybDBwBggrBgEFBQcBAQRkMGIw
JgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3NwLnRydXN0d2F2ZS5jb20vMDgGCCsGAQUF
BzAChixodHRwOi8vc3NsLnRydXN0d2F2ZS5jb20vaXNzdWVycy9PVkNBX0wyLmNy
dDANBgkqhkiG9w0BAQUFAAOCAQEAPm7pdeMacdxfke86QEo/lR8lFlzcpalx/sSE
2GdmWLINFu2k1UbbhBNfqD9QaleKK7UaqxvKNkziJb0QGvQu4zQVjgTgW3X7xEdh
tHRINpAD5Pqn6snhtGLsuEWXngJSVjj8HvEpnZBtEHwsWuoQJhv0JUtHU5hrh96y
AvUrqLCXg52Rb3h6IZxKgsO6yhBtpSHf5W4zW8PCF7v7BD8jRvhn421vQM2MDQUt
0EW8NWu2WU780tBCIGgUDAudDcuv2sDlvSrCl4qw9JvZtxEjvYhxetPWUccTbLz+
uK8T3Pf6/zSE3hLU4w+kslmKflrRzI4aCAAHekPd1+r3RAgt5w==
-----END CERTIFICATE-----
subject=/CN=tshirtsofoz.com.au/O=T-shirts of Oz/L=Adelaide/ST=SA/C=AU
issuer=/C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Organization Validation CA, Level 2/emailAddress=ca#trustwave.com
---
No client certificate CA names sent
---
SSL handshake has read 3217 bytes and written 506 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 94A2EBDFF8EBA3B60B0CBCE497B21FB5753DD07FABFBD21CC2642C2F0665EE34
Session-ID-ctx:
Master-Key: 74BBCA1A44D5A8AAD5FD916C761E349B7FAD876D35B03AB499E20ADBC8170C643917DAF414D8AAE46D5574349DBCBB07
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1409126533
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
HTTP/1.1 302 Moved Temporarily
Date: Wed, 27 Aug 2014 08:01:52 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
X-Powered-By: PHP/5.4.21
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: https://tshirtsofoz.com.au/xmlrpc.php
Set-Cookie: PHPSESSID=9690b2302154849c9f0f4b1583cd6175; path=/
Location: https://tshirtsofoz.com.au/wp-admin/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
closed
Trying to get an HTTPS session working using client certificates from a self-signed CA. The connection should check that all certificates are valid, both client and server side.
The process I followed is roundly as follows:
Create Certificate Authority
openssl genrsa -out CA.key 4096
openssl req -new -key CA.key -out CA.csr
openssl x509 -req -days 365 -in CA.csr -out CA.crt -signkey CA.key
Create Server Certificate
openssl genrsa -out server.key 4096
openssl req -new -key server.key -out server.csr
openssl ca -in server.csr -cert CA.crt -keyfile CA.key -out server.crt
Create Client Certificate
openssl genrsa -out client.key 4096
openssl req -new -key client.key -out client.csr
openssl ca -in client.csr -cert CA.crt -keyfile CA.key -out client.crt
Configure Apache
<VirtualHost _default_:443>
SSLEngine on
SSLCertificateFile "server.crt"
SSLCertificateKeyFile "server.key"
SSLCACertificateFile "CA.crt"
<Directory "/var/www">
SSLVerifyClient optional
SSLVerifyDepth 10
SSLOptions +StdEnvVars +ExportCertData
</Directory>
</VirtualHost>
Now I try and make a test connection:
wget \
--post-data 'id=1234' \
--certificate=client.crt \
--ca-certificate=CA.crt \
https://test.example.com:443
The resulting output from wget shows (over and over), in part:
HTTP request sent, awaiting response... No data received.
Retrying.
Checking the SSL error log from Apache give me the following messages:
[debug] ssl_engine_io.c(1606): [client xx.xx.xx.xx] total of 41 bytes in buffer, eos=1
[client xx.xx.xx.xx] Requesting connection re-negotiation
[debug] ssl_engine_io.c(1908): OpenSSL: I/O error, 5 bytes expected to read on BIO#80b075190 [mem: 80b0ca003]
[debug] ssl_engine_kernel.c(771): [client xx.xx.xx.xx] Performing full renegotiation: complete handshake protocol (client does support secure renegotiation)
[debug] ssl_engine_kernel.c(1892): OpenSSL: Handshake: start
[debug] ssl_engine_kernel.c(1900): OpenSSL: Loop: SSL renegotiate ciphers
[debug] ssl_engine_kernel.c(1900): OpenSSL: Loop: SSLv3 write hello request A
[debug] ssl_engine_kernel.c(1900): OpenSSL: Loop: SSLv3 flush data
[debug] ssl_engine_kernel.c(1900): OpenSSL: Loop: SSLv3 write hello request C
[info] [client xx.xx.xx.xx] Awaiting re-negotiation handshake
[debug] ssl_engine_kernel.c(1892): OpenSSL: Handshake: start
[debug] ssl_engine_kernel.c(1900): OpenSSL: Loop: before accept initialization
[debug] ssl_engine_io.c(1908): OpenSSL: I/O error, 5 bytes expected to read on BIO#80b075190 [mem: 80b0ca003]
[debug] ssl_engine_kernel.c(1929): OpenSSL: Exit: error in SSLv3 read client hello B
[error] [client xx.xx.xx.xx] Re-negotiation handshake failed: Not accepted by client!?
[debug] ssl_engine_io.c(1650): [client xx.xx.xx.xx] read from buffered SSL brigade, mode 0, 8192 bytes
[debug] ssl_engine_io.c(1725): [client xx.xx.xx.xx] buffered SSL brigade exhausted
[debug] ssl_engine_io.c(1650): [client xx.xx.xx.xx] read from buffered SSL brigade, mode 2, 0 bytes
[info] [client XX:XX:XX:XX::xx] Connection to child 3 established (server register.kiosk.tain.com:443)
[info] Seeding PRNG with 656 bytes of entropy
[debug] ssl_engine_kernel.c(1892): OpenSSL: Handshake: start
[debug] ssl_engine_kernel.c(1900): OpenSSL: Loop: before/accept initialization
Run the openssl client to see if there's anything to help in here:
openssl s_client \
-showcerts \
-connect test.example.com:443 \
-cert client.crt \
-key client.key \
-CAfile CA.crt
In the reply I see the following:
---
Server certificate
subject=/C=XX/ST=XXXXX/O=XXXX/CN=test.example.com
issuer=/O=XXXX/L=XXXXX/ST=XXXXX/C=SE/CN=XXXX Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 3846 bytes and written 519 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
"No client certificate CA names sent" looks different to what I am expecting. I want client certificates.
Where am I going wrong?
It doesn't really make sense to talk about a "self-signed CA". Your title ("Self-signed client SSL certificates [...]") suggests you're talking about self-signed client certificate. You're not: you're talking about client certificates issued by your own CA.
You've put your SSLVerifyClient directive within a Directory section, which would imply a re-negotiation to get the client certificate, once the client has made a request trying to access that directory.
Since there is no DocumentRoot directive in your configuration, it's not clear whether a request on / will try to access this directory (this may depend on compilation options depending on how it was packaged, but /var/www isn't the default value otherwise).
Putting SSLVerifyClient directly in your virtual host should at least make openssl s_client see a client-certificate request. Fixing the DocumentRoot might not be enough, since you'd need to make the HTTP request to trigger the renegotiation.