> And, finally:
>
> 4. they DO NOT work when loaded by httpd
>
> I will be the first to admit that I don't really "know" much about
> public key cryptography and how openssl implements things. But, being
> simple, it seems to me that there are really only two possibilities.
>
> Either apache, pound, and openssl s_server are all flawed and are
> incorrectly using an invalid certificate/key pair for encryption; or
> there is a problem in httpd and how it deals with certificates and
> https.
>
> I will try things again tomorrow (later today) and see if I can get
> any info with tcpdump.
>
> If there is anything else to try, please let me know.
Please try 's_client' as I had suggested in an earlier email - it's not
the certificates themselves you should be testing (i.e. with 's_server'
and a web browser) but certificates/keys *with* httpd and a client which
will give you meaningful output ('s_client').
Like I had also mentioned earlier - I had generated a new certificate
and a key and tested it on one of my machines and it all works just
fine.
Last, but not least - if you hadn't done so already,please make sure you
are running the latest snapshot.
Regards,
Raf
----------
First, I installed the most recent snapshot:
OpenBSD 5.7-current (GENERIC.MP) #896: Thu Mar 26 14:56:12 MDT 2015
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
(sorry about the other dmesg snip - I pulled the snip off the top, and I was
not aware that on this system the message buffer
survives a reboot)
First, I started httpd as "httpd -d -v -v -v -v -v -v -v":
The terminal spits back:
startup
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
server_tls_load_keypair: using certificate /etc/ssl/server.crt
server_tls_load_keypair: using private key /etc/ssl/private/server.key
socket_rlimit: max open files 1024
server_privinit: adding server default
server_privinit: adding server default
server_launch: running server default
server_launch: running server default
server_launch: running server default
then, on an second terminal, I tried connecting with: openssl s_client
-connect 127.0.0.1:443
on the second (s_client) terminal, I get:
CONNECTED(00000003)
And that's it.
On the first (httpd) terminal, there is no output of any kind.
So, I waited about 10 seconds, nothing happened, and I shut down httpd. The
terminal says:
^C
logger exiting, pid 14644
server exiting, pid 21849
server exiting, pid 18400
server exiting, pid 10463
parent terminating, pid 9974
Then, I opened a s_server instance: openssl s_server -accept 443 -www -cert
/etc/ssl/server.crt -key /etc/ssl/private/server.key
It gives me:
Using auto DH parameters
Using default temp ECDH parameters
ACCEPT
And on the second terminal I try s_client again: openssl s_client -connect
127.0.0.1:443
And it connects. Here is the output (I XXX'ed some of the certificate info):
openssl s_client -connect 127.0.0.1:443
CONNECTED(00000003)
depth=0 C = US, ST = XXX, O = XXX, OU = XXX, L = XXX, CN = XXX, emailAddress =
XXX
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = XXX, O = XXX, OU = XXX, L = XXX, CN = XXX, emailAddress =
XXX
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = US, ST = XXX, O = XXX, OU = XXX, L = XXX, CN = XXX, emailAddress =
XXX
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=XXX/O=XXX/OU=XXX/L=XXX/CN=XXX/emailAddress=XXX
i:/C=US/ST=XXX/L=XXX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIH6zCCBdOgAwIBAgIBATANBgkqhkiG9w0BAQsFADCBljELMAkGA1UEBhMCVVMx
ETAPBgNVBAgMCElsbGlub2lzMREwDwYDVQQHDAhXaW5uZXRrYTEUMBIGA1UECgwL
<... more certificate block ...>
6RUcfqhZ211+IvAnJVYAsz+1hzLGL57Ppct6HHf41xl36WakU+J3jlpVpIaA8jHh
5ThHy8QM1jeo90XENClcYD2W1OHD75Hchn5pEbA8BfpKJpvTwsosIFdZazWvHHO8
CU8P6Syj53sEw0MeooEt
-----END CERTIFICATE-----
subject=/C=US/ST=XXX/O=XXX/OU=XXX/L=XXX/CN=XXX/emailAddress=XXX
issuer=/C=US/ST=XXX/L=XX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX
---
No client certificate CA names sent
---
SSL handshake has read 2933 bytes and written 438 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305
Session-ID: FC424D25B814891FD0F881B1E20C6367547803E189FF2EB1D337201491CB078A
Session-ID-ctx:
Master-Key:
ADB4316898847559BAF6EE1188F1FCFAB0D741D36A73226D023458247CE26523F74EABE327755A7A12CFB9242AAA9413
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 8c 5f 29 1e 1e a2 9f e3-f8 3e 62 1f 9f 10 ad 5c ._)......>b....\
0010 - be 8c 47 51 98 4c 93 66-bb a9 51 70 93 37 b3 4e ..GQ.L.f..Qp.7.N
0020 - 16 fc 38 fa f6 ea 37 73-9c d4 82 e9 1a 30 f9 44 ..8...7s.....0.D
0030 - eb 5e 4b 4f b2 c5 9e 00-f1 65 5e d5 b8 d7 76 c7 .^KO.....e^...v.
0040 - 59 24 9a 31 4b 9a a6 07-24 c6 53 ae fe 59 75 dd Y$.1K...$.S..Yu.
0050 - 0d d0 2d 7e cf 16 6b b2-4c 7a 57 e6 df 39 7a f6 ..-~..k.LzW..9z.
0060 - d6 d2 00 13 a0 9c ef 77-06 ba a4 36 e6 3d 1c fc .......w...6.=..
0070 - 1d bb a4 11 b8 be d9 e5-b0 f9 20 e9 b7 00 fe 95 .......... .....
0080 - 79 ff 25 bb 94 41 a8 57-2d 0b ea 43 5d fe 95 8e y.%..A.W-..C]...
0090 - c0 b6 8c 69 c6 c8 9e 9e-a0 3d dc 84 4a 19 60 91 ...i.....=..J.`.
Start Time: 1427479549
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
That's it.
(I know that the CA for the cert is not currently trusted by the system above;
but the certificate does work for establishing the
connection with s_client and s_server)
Again, I don't really "know," but it seems to me that openssl s_server is able
to use the certificate without an issue.
However, httpd "loads" the certificate and key at startup, but then refuses to
respond to a connection attempt with that
certificate.
I have NOT tried using another certificate with httpd. I could, and a
different certificate may work just fine. But, that doesn't
seem to be a solution for the problem.
If the certificate is "good" (as demonstrated by s_client and s_server), then
should not httpd "just work" with it?
I don't understand why httpd does not provide any information about the https
connection attempts at all?
Thanks
[demime 1.01d removed an attachment of type application/x-pkcs7-signature which
had a name of smime.p7s]
