Date: Sun, 1 Apr 2018 14:45:32 -0700 From: Bruce Ferrell <bferrell@baywinds.org> To: freebsd@dreamchaser.org, freebsd-questions@freebsd.org Subject: Re: apache24 ssl setup problems; "unknown protocol" Message-ID: <3fe11187-df4f-bdf7-1252-75348faf3ff4@baywinds.org> In-Reply-To: <cc91a72c-f373-3438-c60c-8c519ac2afd9@dreamchaser.org> References: <acd1c4b7-72ce-0fd2-a640-4b3c22299a75@dreamchaser.org> <fc3125a2-14a1-6fe5-cc67-0a32f9361657@baywinds.org> <3ebae04a-4928-7979-9100-b0c3317a5284@dreamchaser.org> <eab52606-6f62-d88f-0682-9fe3ce1f470c@baywinds.org> <210673da-f441-491f-7de4-f4bfbadbf5a5@dreamchaser.org> <80dadfa7-ea5f-4027-f862-e1cd39f5694b@baywinds.org> <cc91a72c-f373-3438-c60c-8c519ac2afd9@dreamchaser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gary, I didn't include the ascii of the cert is all. We both have that openssl s_client -connect 192.168.151.101:443 -showcerts -state This one is interesting - mine: openssl s_client -connect 127.0.0.1:443 -showcerts -state | more SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = baywinds.org verify error:num=10:certificate has expired notAfter=Jan 29 18:50:59 2018 GMT verify return:1 depth=0 CN = baywinds.org notAfter=Jan 29 18:50:59 2018 GMT verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server key exchange A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read server session ticket A SSL_connect:SSLv3 read finished A CONNECTED(00000003) --- Certificate chain 0 s:/CN=baywinds.org i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 yours: SSL_connect:SSLv2/v3 write client hello A SSL_connect:error in SSLv2/v3 read server hello A 34379279064:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:782: indicates a failure in the ssl handshake before crypto starts causing the cert to not be returned. if you do a tcpdump tcpdump -nni <interface> port 443 -s0 -w ssl.pcap Pull that into wireshark, you can see that negotiation go on.... client hello server hello, cert, server key exchange, server hello done client key exchange, change cipher spec, encrypted handshake message new session ticket, change cipher spec, encrypted handshake message If you look at the hello messages, you'll see the supported cyphers for each. I think you'll find there are no ciphers in common and ssl link setup fails. With no secure channel, no cert is returned On 04/01/2018 11:30 AM, Gary Aitken wrote: > On 03/31/18 23:03, Bruce Ferrell wrote: > >> Compare yours against this. Yours seems to say CA: True where mine >> says CA: False. > > The differences I see are as follows (yours first): > Yours: > Serial Number: > 03:ca:27:c0:72:10:33:87:1c:e4:49:84:c3:8e:7a:de:08:d2 > Mine: > Serial Number: 17102700810868824541 (0xed58ffc6039f19dd) > that looks like just a matter of form in terms of the text output > > Issuer: > Yours is an actual CA, lists C,O,CN fields; > mine is self-signed, lists C, ST, L, CN fields > > Validity: > Dates are different but both are current > > X509v3 extensions: > Yours: > X509v3 extensions: > X509v3 Key Usage: critical > Digital Signature, Key Encipherment > X509v3 Extended Key Usage: > TLS Web Server Authentication, TLS Web Client Authentication > X509v3 Basic Constraints: critical > CA:FALSE > X509v3 Subject Key Identifier: > 4B:3D:63:4F:E1:92:2A:7D:44:4D:D7:AC:2D:4E:7C:44:BD:58:EE:20 > X509v3 Authority Key Identifier: > keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1 > Authority Information Access: > OCSP - URI:http://ocsp.int-x3.letsencrypt.org > CA Issuers - URI:http://cert.int-x3.letsencrypt.org/ > > X509v3 Subject Alternative Name: > DNS:baywinds.org > X509v3 Certificate Policies: > Policy: 2.23.140.1.2.1 > Policy: 1.3.6.1.4.1.44947.1.1.1 > CPS: http://cps.letsencrypt.org > User Notice: > Explicit Text: ... > Mine: > X509v3 extensions: > X509v3 Subject Key Identifier: > F0:C6:CB:DE:A6:DC:55:89:C7:3B:0C:AC:67:34:E0:C5:82:FC:6E:DA > X509v3 Authority Key Identifier: > keyid:F0:C6:CB:DE:A6:DC:55:89:C7:3B:0C:AC:67:34:E0:C5:82:FC:6E:DA > > X509v3 Basic Constraints: > CA:TRUE > > Finally, mine has an actual cert at the end, presumably because it > says it is a CA so the cert itself is included? > > The main difference seems to be all of the x509v3 extensions present, > plus the CA false vs true. Makes me wonder if there is some > apache config option which causes it to not work with these kind of > test certs. But if that was the case I would expect something in > the error log other than the message that it read the cert and key. > > Your extensions explicitly indicate "Key Usage" (critical, of two > types; and "Extended Key Usage" for web server and client > authentication; mine does not. But it's not clear to me how to get > those into a test cert. > > If I startup with a different cert without a fqdn matching the > server name, I see messages in the log notifying me of this but it > still starts up and says it is using the cert. Those are warnings > only, so I presume should work ok: > > [ssl:debug] [pid 18520] ssl_engine_init.c(412): AH01893: Configuring TLS extension handling > [ssl:info] [pid 18520] AH02575: Reusing existing private key from /etc/ssl/test3_cert.key on restart > [ssl:warn] [pid 18520] AH01906: www.dreamchaser.org:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?) > [ssl:debug] [pid 18520] ssl_util_ssl.c(443): AH02412: [www.dreamchaser.org:443] Cert does not match for name 'www.dreamchaser.org' [subject: CN=Gary Aitken,L=Ovando,ST=MT,C=US / > issuer: CN=Gary Aitken,L=Ovando,ST=MT,C=US / serial: E20611662B12B685 / notbefore: Apr 1 17:48:44 2018 GMT / notafter: Mar 31 17:48:44 2020 GMT] > [ssl:warn] [pid 18520] AH01909: www.dreamchaser.org:443:0 server certificate does NOT include an ID which matches the server name > [ssl:info] [pid 18520] AH02568: Certificate and private key www.dreamchaser.org:443:0 configured from /etc/ssl/test3_cert.crt and /etc/ssl/test3_cert.key > > More questions: > > When I hit the server with: > openssl s_client -connect 192.168.151.101:443 -showcerts -state > I get back: > > SSL_connect:SSLv2/v3 write client hello A > SSL_connect:error in SSLv2/v3 read server hello A > 34379279064:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:782: > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 291 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1.2 > Cipher : 0000 > Session-ID: > Session-ID-ctx: > Master-Key: > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1522605618 > Timeout : 300 (sec) > Verify return code: 0 (ok) > --- > > Does the "no peer certificate available" mean the client did not get > a cert back from the server, or is it a complaint from the server > saying the client didn't send a cert? > > The unknown protocol message bothers me. Does this mean: > A. the default crypto library port build is missing something > needed by apache24? > B. the client crypto library is missing something? > C. The client is requesting a garbled up protocol the server > doesn't know about? > D. The server is telling the client it (the server) wants a > protocol the client doesn't know about? > E. My "openssl s_client ..." command needs some extra args? > I presume the client needs no certs/keys on its end, right? > > libgcrypt on the server is 1.7.6 but 1.8.2 on the client, but there > are no port options other than docs. The latest notice in UPDATING > is dated 20130503, so it seems like the versioning shouldn't be an > issue. > > still bewildered... > > Gary >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3fe11187-df4f-bdf7-1252-75348faf3ff4>