Date: Sun, 1 Apr 2018 12:30:51 -0600 From: Gary Aitken <freebsd@dreamchaser.org> To: Bruce Ferrell <bferrell@baywinds.org>, freebsd-questions@freebsd.org Subject: Re: apache24 ssl setup problems; "unknown protocol" Message-ID: <cc91a72c-f373-3438-c60c-8c519ac2afd9@dreamchaser.org> In-Reply-To: <80dadfa7-ea5f-4027-f862-e1cd39f5694b@baywinds.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?cc91a72c-f373-3438-c60c-8c519ac2afd9>