apache24 ssl setup problems; "unknown protocol"

Bruce Ferrell bferrell at baywinds.org
Sun Apr 1 21:45:42 UTC 2018

Gary, I didn't include the ascii of the cert is all.  We both have that

openssl s_client -connect -showcerts -state

This one is interesting - mine:

openssl s_client -connect -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
Certificate chain
  0 s:/CN=baywinds.org
    i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3


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:
>                 Policy:
>                   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 -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

More information about the freebsd-questions mailing list