> On Thu, 26 Mar 2015 08:30:23 +0100
> mxb wrote:
>
>> >
>> > Thank you for the suggestion. I was not aware of "pound."
>>
>> I?d rather go for relayd. Which is out of the box. No need to install ?yet
>> another port and make sure it is up2date?.
>
> httpd is based on relayd code which would reduce the scope of the test
> (a cluestick).
>
>>> When I try "https://10.0.128.67/index.html"; - I get a nice message from
>>> firefox asking me to accept a problem certificate (this was expected,
>>> the certificate is the "correct" one), and when I do accept the
>>> certificate, I get the index page.
>
>>> So, I am not sure what is wrong, but it appears httpd is not responding
>>> to https requests, even with the "listen on tls" line in the
>>> configuration file.
>
>>> Is there anything for me to look at/consider in trying to correct this?
>
> I don't understand what you are saying by '"correct" one' but to me this
> suggests you have issues even with pound and perhaps I would try
> another browser or firefox on another client and try another
> certificate perhaps from another CA or install a newer snapshot or
> re-install a release before wondering if there is an issue with httpd
> or libressl whilst monitoring the list to see if anyone else has an
> issue?
>
> Thankfully re-install on OpenBSD is super quick but you do have to
> follow www.openbsd.org/current.html for snapshots and I think
> www.openbsd.org/plus.html for release upgrades (4.5 -> 4.6 etc.)
>
>
Hello:
I started httpd as: httpd -d -v -v -v -v -v -v -v
And I see:
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
but, if I try to connect using https, there is no output on the terminal
indicating that httpd is doing anything at all.
Ctrl-c to kill the server gives:
^C
logger exiting, pid 28447
server exiting, pid 23445
server exiting, pid 20653
server exiting, pid 12690
parent terminating, pid 29581
So, it seems that httpd does, in fact, see the cert and key, but does nothing
with them.
(the cert is PEM encoded)
So, I also tried:
openssl s_server -accept 443 -www -cert /etc/ssl/server.crt -key
/etc/ssl/private/server.key
and then connected to the machine with a browser.
This connection works without an issue.
The output to the browser from openssl s_server is:
s_server -accept 443 -www -cert /etc/ssl/server.crt -key
/etc/ssl/private/server.key
Secure Renegotiation IS supported
Ciphers supported in s_server binary
TLSv1/SSLv3:ECDHE-ECDSA-CHACHA20-POLY1305TLSv1/SSLv3:ECDHE-RSA-CHACHA20-POLY1305
TLSv1/SSLv3:DHE-RSA-CHACHA20-POLY1305TLSv1/SSLv3:ECDHE-RSA-AES256-GCM-SHA384
TLSv1/SSLv3:ECDHE-ECDSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDHE-RSA-AES256-SHA384
TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA384TLSv1/SSLv3:ECDHE-RSA-AES256-SHA
TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA TLSv1/SSLv3:DHE-DSS-AES256-GCM-SHA384
TLSv1/SSLv3:DHE-RSA-AES256-GCM-SHA384TLSv1/SSLv3:DHE-RSA-AES256-SHA256
TLSv1/SSLv3:DHE-DSS-AES256-SHA256 TLSv1/SSLv3:DHE-RSA-AES256-SHA
TLSv1/SSLv3:DHE-DSS-AES256-SHA TLSv1/SSLv3:GOST2012256-GOST89-GOST89
TLSv1/SSLv3:DHE-RSA-CAMELLIA256-SHA256TLSv1/SSLv3:DHE-DSS-CAMELLIA256-SHA256
TLSv1/SSLv3:DHE-RSA-CAMELLIA256-SHA TLSv1/SSLv3:DHE-DSS-CAMELLIA256-SHA
TLSv1/SSLv3:GOST2001-GOST89-GOST89 TLSv1/SSLv3:ECDH-RSA-AES256-GCM-SHA384
TLSv1/SSLv3:ECDH-ECDSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDH-RSA-AES256-SHA384
TLSv1/SSLv3:ECDH-ECDSA-AES256-SHA384 TLSv1/SSLv3:ECDH-RSA-AES256-SHA
TLSv1/SSLv3:ECDH-ECDSA-AES256-SHA TLSv1/SSLv3:AES256-GCM-SHA384
TLSv1/SSLv3:AES256-SHA256 TLSv1/SSLv3:AES256-SHA
TLSv1/SSLv3:CAMELLIA256-SHA256 TLSv1/SSLv3:CAMELLIA256-SHA
TLSv1/SSLv3:ECDHE-RSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDHE-ECDSA-AES128-GCM-SHA256
TLSv1/SSLv3:ECDHE-RSA-AES128-SHA256 TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA256
TLSv1/SSLv3:ECDHE-RSA-AES128-SHA TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA
TLSv1/SSLv3:DHE-DSS-AES128-GCM-SHA256TLSv1/SSLv3:DHE-RSA-AES128-GCM-SHA256
TLSv1/SSLv3:DHE-RSA-AES128-SHA256 TLSv1/SSLv3:DHE-DSS-AES128-SHA256
TLSv1/SSLv3:DHE-RSA-AES128-SHA TLSv1/SSLv3:DHE-DSS-AES128-SHA
TLSv1/SSLv3:DHE-RSA-CAMELLIA128-SHA256TLSv1/SSLv3:DHE-DSS-CAMELLIA128-SHA256
TLSv1/SSLv3:DHE-RSA-CAMELLIA128-SHA TLSv1/SSLv3:DHE-DSS-CAMELLIA128-SHA
TLSv1/SSLv3:ECDH-RSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDH-ECDSA-AES128-GCM-SHA256
TLSv1/SSLv3:ECDH-RSA-AES128-SHA256 TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA256
TLSv1/SSLv3:ECDH-RSA-AES128-SHA TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA
TLSv1/SSLv3:AES128-GCM-SHA256 TLSv1/SSLv3:AES128-SHA256
TLSv1/SSLv3:AES128-SHA TLSv1/SSLv3:CAMELLIA128-SHA256
TLSv1/SSLv3:CAMELLIA128-SHA TLSv1/SSLv3:IDEA-CBC-SHA
TLSv1/SSLv3:ECDHE-RSA-RC4-SHA TLSv1/SSLv3:ECDHE-ECDSA-RC4-SHA
TLSv1/SSLv3:ECDH-RSA-RC4-SHA TLSv1/SSLv3:ECDH-ECDSA-RC4-SHA
TLSv1/SSLv3:RC4-SHA TLSv1/SSLv3:RC4-MD5
TLSv1/SSLv3:ECDHE-RSA-DES-CBC3-SHA TLSv1/SSLv3:ECDHE-ECDSA-DES-CBC3-SHA
TLSv1/SSLv3:EDH-RSA-DES-CBC3-SHA TLSv1/SSLv3:EDH-DSS-DES-CBC3-SHA
TLSv1/SSLv3:ECDH-RSA-DES-CBC3-SHA TLSv1/SSLv3:ECDH-ECDSA-DES-CBC3-SHA
TLSv1/SSLv3:DES-CBC3-SHA TLSv1/SSLv3:EDH-RSA-DES-CBC-SHA
TLSv1/SSLv3:EDH-DSS-DES-CBC-SHA TLSv1/SSLv3:DES-CBC-SHA
---
Ciphers common between both SSL end points:
ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-RC4-SHA ECDHE-RSA-RC4-SHA DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA DHE-RSA-AES256-SHA AES128-SHA
AES256-SHA DES-CBC3-SHA RC4-SHA
RC4-MD5
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID:
Session-ID-ctx: 01000000
Master-Key:
1BBE416FBC2A5BC14C957C90A7D2D18DC916D1AE6366F14FC453BB1E383509E113F0B04754FFD09FC786D04E2CB79343
Start Time: 1427434365
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
0 items in the session cache
0 client connects (SSL_connect())
0 client renegotiates (SSL_connect())
0 client connects that finished
2 server accepts (SSL_accept())
0 server renegotiates (SSL_accept())
2 server accepts that finished
0 session cache hits
0 session cache misses
0 session cache timeouts
0 callback cache hits
0 cache full overflows (128 allowed)
---
no client certificate available
I am not really sure what this all means, but, from my simplistic point of
view, it seems that my cert and key:
1. work when they are installed on another machine running apache and
successfully serve https pages
2. they are correctly used by pound (on the "problem" machine) when it listens
and accepts https connections which it then forwards
to httpd
3. they are recognized and used by openssl s_server (on the "problem" machine)
and are able to accept https connections
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.
Thanks
Ted
[demime 1.01d removed an attachment of type application/x-pkcs7-signature which
had a name of smime.p7s]
