Frustration doesn't begin to express it! SEC Productions presents:
* THE CLIENT AND SERVER AUTH SAGA *
lets get on with it:
complete walkthrough of ssl cert creation -----------------------------------------
By the way, please don't lecture me on ssh'ing into machines as root, they are located on an isolated network and of course, all logging in as root is disabled when they are put into production. :)
There now follows a step by step account of everything so far...
command prompt key:
ca# = certificate authority machine (or my isolated desktop, whichever you prefer). records# = log server dns# = my dns server (the logging client)
(obvious output of scripts snipped)
-----------------------------------------
ca# cd /etc/ssl/misc ca# ./CA.sh -newca
<snip>
ca# ./CA.sh -newreq
<snip>
Request (and private key) is in newreq.pem
ca# ./CA.sh -sign Signed certificate is in newcert.pem
ca# cat newreq.pem newcert.pem > log_server.pem
Then I realised that I needed it to be passwordless.
ca# openssl rsa -in newreq.pem -out decryptedcert.pem
ca# cat decryptedcert.pem newcert.pem > log_server_np.pem
(log_server_np.pem is now passwordless)
ca# scp log_server_np.pem records:/etc/ssl/stunnel_cert/ ca# scp demoCA/cacert.pem dns:/var/stunnel/cert/cacert.pem
we'll just try with server side auth at the moment, on the loghost:
records# cat /etc/stunnel/stunnel.conf
cert = /etc/ssl/stunnel_cert/log_server_np.pem chroot = /var/stunnel pid = /var/run/stunnel.pid
CApath = /certs CRLpath = /crls
#verify = 2
debug = 7 output = stunnel.log
setuid = _stunnel setgid = _stunnel
[syslogngs] accept = 192.168.1.9:5514 connect = 127.0.0.1:5515
on the client:
dns# cat /etc/stunnel/stunnel.conf
#cert = /etc/stunnel/cert/clientkeycert.pem chroot = /var/stunnel pid = /var/run/stunnel.pid
CAfile = /certs/cacert.pem CRLpath = /crls
debug = 7 output = stunnel.log
client = yes
setuid = _stunnel setgid = _stunnel
[syslogngs] accept = 127.0.0.1:5515 connect = 192.168.1.9:5514
looks good...
dns# telnet localhost 5515
(in the interests of patience and readability, the output of stunnel.log isn't posted here, suffice to say the connection is successful and works)
now to step up to client and server authentication.
ca# openssl req -x509 -newkey rsa:2048 -keyout clientkey.pem -out \ clientcert -days 365
(forgot to use -nodes)
ca# openssl rsa -in clientkey.pem -out client_decrypted_key.pem ca# cat clientkey.pem clientcert.pem > clientkeycert.pem ca# ./c_hash clientkeycert.pem 4410a4d9.0 => clientkeycert.pem
ca# scp clientkeycert.pem dns:/etc/stunnel/cert ca# scp clientcert.pem records:/var/stunnel/certs
on the server:
records# ln -s /var/stunnel/certs/clientcert.pem \ /var/stunnel/certs/4410a4d9.0 adjust the stunnel.conf on both hosts accordingly:
records# cat /etc/stunnel/stunnel.conf
cert = /etc/ssl/stunnel_cert/log_server_np.pem chroot = /var/stunnel pid = /var/run/stunnel.pid
CApath = /certs CRLpath = /crls
verify = 3
debug = 7 output = stunnel.log
setuid = _stunnel setgid = _stunnel
[syslogngs] accept = 192.168.1.9:5514 connect = 127.0.0.1:5515
dns# cat /etc/stunnel/stunnel.conf
cert = /etc/stunnel/cert/clientkeycert.pem chroot = /var/stunnel pid = /var/run/stunnel.pid
CAfile = /certs/cacert.pem CRLpath = /crls
debug = 7 output = stunnel.log
client = yes
setuid = _stunnel setgid = _stunnel
[syslogngs] accept = 127.0.0.1:5515 connect = 192.168.1.9:5514 and just to show the permissions:
records# ls -al /etc/ssl/ drwx------ 2 _stunnel _stunnel 512 Aug 30 12:19 stunnel_cert
records# ls -al /etc/ssl/stunnel_cert -rw------- 1 _stunnel _stunnel 4320 Aug 30 12:19 log_server_np.pem
records# ls -al /var/stunnel/certs/ lrwxr-xr-x 1 root _stunnel 33 Aug 30 14:33 4410a4d9.0 -> /var/stunnel/certs/clientcert.pem -rw------- 1 _stunnel _stunnel 1489 Aug 30 14:32 clientcert.pem
dns# ls -al /etc/stunnel/dns# ls -al /etc/stunnel/ drwx------ 3 _stunnel _stunnel 512 Aug 29 21:50 . drwx------ 2 _stunnel _stunnel 512 Aug 30 14:18 cert -rw------- 1 _stunnel _stunnel 301 Aug 30 14:22 stunnel.conf -rw------- 1 _stunnel _stunnel 13401 Aug 29 22:21 stunnel.log
dns# ls -al /etc/stunnel/cert/ -rw------- 1 _stunnel _stunnel 3168 Aug 30 14:18 clientkeycert.pem
dns# ls -al /var/stunnel/ drwx------ 5 _stunnel _stunnel 512 Aug 29 21:28 . drwx------ 2 _stunnel _stunnel 512 Aug 30 13:59 cert drwx------ 2 _stunnel _stunnel 512 Aug 29 21:16 crl drwx------ 3 _stunnel _stunnel 512 Aug 29 21:28 var
dns# ls -al /var/stunnel/cert/ drwx------ 2 _stunnel _stunnel 512 Aug 30 13:59 . -rw------- 1 _stunnel _stunnel 1115 Aug 30 13:59 cacert.pem
now, to test.
records# /usr/local/sbin/stunnel /etc/stunnel/stunnel.conf
dns# /usr/local/sbin/stunnel /etc/stunnel/stunnel.conf
the log files on both show no errors, lets try a connection from dns to records...
dns# telnet localhost 5515 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host.
urgh! what went wrong?
records# cat stunnel.log
2004.08.30 14:46:43 LOG5[27205:1006690304]: stunnel 4.05 on i386-unknown-openbsd3.5 PTHREAD with OpenSSL 0.9.7c 30 Sep 2003 2004.08.30 14:46:43 LOG7[27205:1006690304]: Snagged 64 random bytes from /dev/arandom 2004.08.30 14:46:43 LOG7[27205:1006690304]: RAND_status claims sufficient entropy for the PRNG 2004.08.30 14:46:43 LOG6[27205:1006690304]: PRNG seeded successfully 2004.08.30 14:46:43 LOG7[27205:1006690304]: Certificate: /etc/ssl/stunnel_cert/log_server_np.pem 2004.08.30 14:46:43 LOG7[27205:1006690304]: Key file: /etc/ssl/stunnel_cert/log_server_np.pem 2004.08.30 14:46:43 LOG7[27205:1006690304]: Verify directory set to /certs 2004.08.30 14:46:43 LOG7[27205:1006690304]: CRL directory set to /crls 2004.08.30 14:46:43 LOG5[27205:1006690304]: Peer certificate location /certs 2004.08.30 14:46:43 LOG5[27205:1006690304]: FD_SETSIZE=1024, file ulimit=128 -> 61 clients allowed 2004.08.30 14:46:43 LOG7[27205:1006690304]: FD 10 in non-blocking mode 2004.08.30 14:46:43 LOG7[27205:1006690304]: SO_REUSEADDR option set on accept socket 2004.08.30 14:46:43 LOG7[27205:1006690304]: syslogngs bound to 192.168.1.9:5514 2004.08.30 14:46:43 LOG7[27205:1006690304]: FD 11 in non-blocking mode 2004.08.30 14:46:43 LOG7[27205:1006690304]: FD 12 in non-blocking mode 2004.08.30 14:46:43 LOG7[20297:1006690304]: Created pid file /var/run/stunnel.pid 2004.08.30 14:46:51 LOG7[20297:1006690304]: syslogngs accepted FD=13 from 192.168.1.6:7109 2004.08.30 14:46:51 LOG7[20297:1006690304]: FD 13 in non-blocking mode 2004.08.30 14:46:51 LOG7[20297:1006693376]: syslogngs started 2004.08.30 14:46:51 LOG5[20297:1006693376]: syslogngs connected from 192.168.1.6:7109 2004.08.30 14:46:51 LOG7[20297:1006693376]: SSL state (accept): before/accept initialization 2004.08.30 14:46:51 LOG7[20297:1006693376]: SSL state (accept): SSLv3 read client hello A 2004.08.30 14:46:51 LOG7[20297:1006693376]: SSL state (accept): SSLv3 write server hello A 2004.08.30 14:46:51 LOG7[20297:1006693376]: SSL state (accept): SSLv3 write certificate A 2004.08.30 14:46:51 LOG7[20297:1006693376]: SSL state (accept): SSLv3 write certificate request A 2004.08.30 14:46:51 LOG7[20297:1006693376]: SSL state (accept): SSLv3 flush data 2004.08.30 14:46:51 LOG7[20297:1006693376]: waitforsocket: FD=13, DIR=read 2004.08.30 14:46:52 LOG7[20297:1006693376]: waitforsocket: ok 2004.08.30 14:46:52 LOG4[20297:1006693376]: VERIFY ERROR: depth=0, error=self signed certificate: /C=UK/L=London/O=SI/OU=SEC/CN=LogClient/emailAddress=root@localhost 2004.08.30 14:46:52 LOG7[20297:1006693376]: SSL alert (write): fatal: bad certificate 2004.08.30 14:46:52 LOG3[20297:1006693376]: SSL_accept: 140890B2: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned 2004.08.30 14:46:52 LOG7[20297:1006693376]: syslogngs finished (0 left)
--- dns# cat stunnel.log
2004.08.30 14:33:24 LOG5[10920:1006690304]: stunnel 4.05 on i386-unknown-openbsd3.5 PTHREAD with OpenSSL 0.9.7c 30 Sep 2003 2004.08.30 14:33:24 LOG7[10920:1006690304]: Snagged 64 random bytes from /dev/arandom 2004.08.30 14:33:24 LOG7[10920:1006690304]: RAND_status claims sufficient entropy for the PRNG 2004.08.30 14:33:24 LOG6[10920:1006690304]: PRNG seeded successfully 2004.08.30 14:33:24 LOG7[10920:1006690304]: Certificate: /etc/stunnel/cert/clientkeycert.pem 2004.08.30 14:33:24 LOG7[10920:1006690304]: Key file: /etc/stunnel/cert/clientkeycert.pem 2004.08.30 14:33:24 LOG5[10920:1006690304]: FD_SETSIZE=1024, file ulimit=128 -> 61 clients allowed 2004.08.30 14:33:24 LOG7[10920:1006690304]: FD 10 in non-blocking mode 2004.08.30 14:33:24 LOG7[10920:1006690304]: SO_REUSEADDR option set on accept socket 2004.08.30 14:33:24 LOG7[10920:1006690304]: syslogngs bound to 127.0.0.1:5515 2004.08.30 14:33:24 LOG7[10920:1006690304]: FD 11 in non-blocking mode 2004.08.30 14:33:24 LOG7[10920:1006690304]: FD 12 in non-blocking mode 2004.08.30 14:33:24 LOG7[11717:1006690304]: Created pid file /var/run/stunnel.pid 2004.08.30 14:33:30 LOG7[11717:1006690304]: syslogngs accepted FD=13 from 127.0.0.1:20109 2004.08.30 14:33:30 LOG7[11717:1006690304]: FD 13 in non-blocking mode 2004.08.30 14:33:30 LOG7[11717:1006693376]: syslogngs started 2004.08.30 14:33:30 LOG5[11717:1006693376]: syslogngs connected from 127.0.0.1:20109 2004.08.30 14:33:30 LOG7[11717:1006693376]: FD 14 in non-blocking mode 2004.08.30 14:33:30 LOG7[11717:1006693376]: syslogngs connecting 192.168.1.9:5514 2004.08.30 14:33:30 LOG7[11717:1006693376]: remote connect #1: EINPROGRESS: retrying 2004.08.30 14:33:30 LOG7[11717:1006693376]: waitforsocket: FD=14, DIR=write 2004.08.30 14:33:30 LOG7[11717:1006693376]: waitforsocket: ok 2004.08.30 14:33:30 LOG7[11717:1006693376]: Remote FD=14 initialized 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): before/connect initialization 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 write client hello A 2004.08.30 14:33:30 LOG7[11717:1006693376]: waitforsocket: FD=14, DIR=read 2004.08.30 14:33:30 LOG7[11717:1006693376]: waitforsocket: ok 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 read server hello A 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 read server certificate A 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 read server certificate request A 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 read server done A 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 write client certificate A 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 write client key exchange A 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 write certificate verify A 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 write change cipher spec A 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 write finished A 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL state (connect): SSLv3 flush data 2004.08.30 14:33:30 LOG7[11717:1006693376]: waitforsocket: FD=14, DIR=read 2004.08.30 14:33:30 LOG7[11717:1006693376]: waitforsocket: ok 2004.08.30 14:33:30 LOG7[11717:1006693376]: SSL alert (read): fatal: bad certificate 2004.08.30 14:33:30 LOG3[11717:1006693376]: SSL_connect: 14094412: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate 2004.08.30 14:33:30 LOG7[11717:1006693376]: syslogngs finished (0 left)
(sorry about the unwrapped lines)
I've also tried using ktrace, but the ktrace.out drops off before the connection (making it useless). I don't understand what can be wrong, I've retraced my steps over and over. I did actually have it working before, but due to testing, reinstalled the OS and now it doesn't work. I'm loathe to install the developement tools, as there are so many it would be a nightmare to remove them after (prompting a reinstall, and look what happened last time).
Any ideas? Anything I've done blindingly obviously wrong?
Why did it work before and not now?
ARGH!
cheers mark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 30 of August 2004 16:04, [email protected] wrote:
By the way, please don't lecture me on ssh'ing into machines as root, they are located on an isolated network and of course, all logging in as root is disabled when they are put into production. :)
IMHO the only good reason to avoid direct root logins is to provide accountability on systems with more than one administrator. In other words I don't see any good reason to avoid direct root login on systems with only one administrator.
chroot = /var/stunnel CAfile = /certs/cacert.pem
CAfile is *not* relative to chroot. 8-)
records# ls -al /var/stunnel/certs/ lrwxr-xr-x 1 root _stunnel 33 Aug 30 14:33 4410a4d9.0 -> /var/stunnel/certs/clientcert.pem -rw------- 1 _stunnel _stunnel 1489 Aug 30 14:32 clientcert.pem
CApath *is* relative to chroot. Your symlink won't work in chroot jail. 8-)
I recommend to use CAfile instead of CApath for simple configurations. It doesn't need a hashed directory and is not relative to chroot jail.
Best regards, Mike
On Mon, Aug 30, 2004 at 08:04:38PM +0200, Michal Trojnara wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 30 of August 2004 16:04, [email protected] wrote:
By the way, please don't lecture me on ssh'ing into machines as root, they are located on an isolated network and of course, all logging in as root is disabled when they are put into production. :)
IMHO the only good reason to avoid direct root logins is to provide accountability on systems with more than one administrator. In other words I don't see any good reason to avoid direct root login on systems with only one administrator.
To be honest, I'm just generally paranoid. I'd rather have a prospective attacker have to crack two passwords (the root and one wheel group) than one. I thought I'd write the above just so I didn't get a big lecture, hehe. :)
chroot = /var/stunnel CAfile = /certs/cacert.pem
CAfile is *not* relative to chroot. 8-)
records# ls -al /var/stunnel/certs/ lrwxr-xr-x 1 root _stunnel 33 Aug 30 14:33 4410a4d9.0 -> /var/stunnel/certs/clientcert.pem -rw------- 1 _stunnel _stunnel 1489 Aug 30 14:32 clientcert.pem
CApath *is* relative to chroot. Your symlink won't work in chroot jail. 8-)
I recommend to use CAfile instead of CApath for simple configurations. It doesn't need a hashed directory and is not relative to chroot jail.
So something like:
CApath = /var/stunnel/certs
I'm paranoid that someone has been at my testing configs now. :) I previously had a working setup, which worries me even further as I *did* use a symlink.
Thanks for the info, I'll give it a go soon. Perhaps I'll also start doing minor backups of the test machines...
Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBM2w2/NU+nXTHMtERAqQmAKCAZ/Vv9LRIyhw+Ca0ECrJ0lxA85QCgyKfS 9s089i9FYP9xcIN+qzsyYzo= =kOzG -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 30 of August 2004 20:38, [email protected] wrote:
To be honest, I'm just generally paranoid. I'd rather have a prospective attacker have to crack two passwords (the root and one wheel group) than one. I thought I'd write the above just so I didn't get a big lecture, hehe. :)
You're not paranoid enough. You still use passwords! 8-)
I recommend to use CAfile instead of CApath for simple configurations. It doesn't need a hashed directory and is not relative to chroot jail.
So something like:
CApath = /var/stunnel/certs
No! CAfile = /var/stunnel/certs/your_cert.pem
I'm paranoid that someone has been at my testing configs now. :) I previously had a working setup, which worries me even further as I *did* use a symlink.
Yes, you can use symlinks, but instead of: ln -s /a/b/c/x /a/b/c/y use: cd /a/b/c ln -s x y Please notice (ls -l) the results are not the same!
Best regards, Mike
-
markzero＠logik.ath.cx -
Michal Trojnara