rootninja

The s_client and s_server options provide a way to launch SSL-enabled command-line clients and servers

If you’re trying to configure a service that includes a TLS/SSL handshake and you want to know if the problem you’re experiencing is related to the application, firewall, certificate trust, misconfiguration, etc. here’s a way to eliminate TLS/SSL from your list of usual suspects.

I’m trying to use an Active Directory Domain Controller to supply a list of objects for an application running on a Linux machine, and I want to make sure the TLS/SSL is working, is trusted, and has nothing to do with the problem i’m having. The only thing the app tells me is “Unable to read schema”

First i’ll verify that my certificate is trusted. Lets see who issued my certificate.

# openssl x509 -noout -in rootninja.crt -issuer

issuer= /DC=com/DC=DOMAIN/CN=rootserver

Now I know which CA this came from, i’ll make sure I use that CA instead of whatever default one it might look at

# openssl verify -CApath /etc/pki/tls/ -CAfile rootserver.pem

rootserver.crt: OK

So now I know this certificate is blessed by my client, I can try to use it to connect. But let’s say I try to use a self-signed certificate or another cert that’s not trusted…

If it’s a trust issue, perhaps the certificate is valid, but it just can’t find the CA or intermediate certificate.

$ openssl s_client -connect rootserver.rootninja.com:636

CONNECTED(00000003)
depth=0 /CN=domainCA.rootninja.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=domainCA.rootninja.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /CN=domainCA.rootninja.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=domainCA.domain.com
   i:/DC=com/DC=domain/CN=dc1.domain.com
-----BEGIN CERTIFICATE-----
...

...
Verify return code: 21 (unable to verify the first certificate)
---

And using a self-signed certificate, you should see something like this.

CONNECTED(00000003)
depth=0 /C=US/ST=State/L=City/O=organization/CN=ldap01.rootninja.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=State/L=City/O=organization/CN=ldap01.rootninja.com
verify return:1
...

...
No client certificate CA names sent
---
SSL handshake has read 983 bytes and written 331 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
...

...
    Verify return code: 18 (self signed certificate)
---

But, if everythings working correctly, your client should connect just fine. And it will look something like this, with a big fat Verify return code: 0 (ok) at the end.

CONNECTED(00000003)
depth=2 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
verify return:1
depth=1 /C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
verify return:1
depth=0 /CN=rootserver.rootninja.com/OU=Domain Control Validated
verify return:1
---
Certificate chain
 0 s:/CN=rootserver.rootninja.com/OU=Domain Control Validated
   i:/C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
 1 s:/C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
...

...
-----END CERTIFICATE-----
subject=/CN=rootserver.rootninja.com/OU=Domain Control Validated
issuer=/C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
---
Acceptable client certificate CA names
/CN=rootserver.rootninja.com/OU=Domain Control Validated
/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/DC=com/DC=microsoft/CN=Microsoft Root CA
/CN=NT AUTHORITY
---
SSL handshake has read 4561 bytes and written 355 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 7407077777C77707177C7
    Session-ID-ctx:
    Master-Key: 7A97FE707C7078797B7437075E7F7267F5787E
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1234567890
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

http://www.openssl.org/

howto, security certificate, handshake, https, ldap, ldaps, openldap, openssl, self-signed certificate, ssl, s_client, tls

If you submit an SSL certificate request for your Apache/Lighttpd web server to a Certificate Authority (CA) on a Windows Domain Controller, you might have to convert your resulting binary DER formatted Security Certificate into PEM so Apache or Lighttpd can understand it.

Convert a certificate from DER to PEM

# openssl x509 –in input.crt –inform DER –out output.crt –outform PEM

Convert a certificate from PEM to DER

# openssl x509 –in input.crt –inform PEM –out output.crt –outform DER

Convert a key from DER to PEM

# openssl rsa –in input.key –inform DER –out output.key –outform PEM

Convert a key from PEM to DER

# openssl rsa –in input.key –inform PEM –out output.key –outform DER

If you’re using Lighttpd, concatenate the key and pem cert so they’re both in one file. If your key has a password (openssl probably forced you to supply a password when you created the request), then you need to strip the password from it first unless you don’t mind having to supply the password every time you start the web server. I know most people don’t stop/start their server very often, but what about in a power failure, or in a remote location?

# openssl rsa -in server.key.original -out server.key.nopass
Enter pass phrase for server.key.original:
writing RSA key

howto, security certificate, der, key, openssl, pem, RSA, ssl, x509

Say you have a default index.html at your web root that you want to be available via http or https, so anyone can get to it. But you have a mediawiki installation that you don’t want accessible unencrypted. So you’re going to redirect all http requests to the wiki over to https:443 and while you’re at it, you don’t want to see “wiki” or “w” (or whatever base directory you’re using), to show up at all.

I’ve read in a bunch of places that you can’t use HTTP["scheme"] to redirect unencrypted http:80 traffic to encrypted https:443 without using two or three levels of nesting using “socket” and/or “host”. But that’s just not true. The only reason it doesn’t seem to work right off the bat is because using =~ with the string “http” includes “https”, so unless you get more specific and end the string with a dollar sign, you get a looping redirect of an https redirect redirecting to itself.

You also end up with a cleaner URL. Instead of http://myserver/wiki/index.php you end up with https://mysever/index.php

And if you haven’t set it up yet, here’s what you’ll need to get SSL working so that lighty’s listening for that redirect.

Don’t forget to put your server.pem ssl cert in that pemfile directory and change wiki to w or whatever your wiki root is. I also had to change $wgScriptPath to null in the wiki’s LocalSettings.php, otherwise it would always look for “/wiki”

Make sure “mod_redirect” is enabled in lighttpd.conf, restart the service and you’re done.

howto, security http, https, lighttpd, lighttpd.conf, lighty, LocalSettings.php, mediawiki, redirect, ssl

Setup a place to call home for your certificate

Here’s where the magic happens… If you want a trusted CA on the internet, you’ll just want to create a certificate signing request, but a self-signed cert will do just fine. I made it good for ~10 years, but standard is probably just 365 days.

Protect your ssl cert and directory.

Now edit the lighttpd.conf configuration file to enable ssl. Use the public facing interface’s IP address instead of mine, unless yours happens to be 192.168.1.2 too!

Restart the server and you should be able to connect via http:// or https://

And nmap or netstat will let you know it’s listening on port 443

Linux, howto, security 443, certificates, certs, https, lighttpd, netstat, nmap, ssl

Enabling LDAP authentication should take you about 2 minutes, unless you type with just 2 fingers. Then maybe 3 or 4.

Uncomment “mod_auth” in /etc/lighttpd/lighttpd.conf

Enable debugging info so you can figure out whats wrong if things don’t go smoothly right off the bat.

Here’s the minimal part you’ll need to get going. Add these lines to your lighttpd.conf and customize as needed.

If you don’t allow anonymous connections to your ldap, give it a user/password combination that has enough privs to do the lookups, or just use your master account if you’re just testing or don’t really care.

Now tell it what parts of your webserver you want to protect and how. You can specify any string you’d like for the realm. Here I require an LDAP user account name and password just to get to the wiki main page, and only admin can see the server-config page.

Restart lighttpd and you’re done. I require encrypted connections for my ldap and this works right out of the box. If you run ldapsearch -xZZ it will force encryption or die. So if you’re not seeing a bunch of entries… well there could be a ton of reasons, like no anonymous binds allowed, or perhaps there’s a firewall issue, etc. If it does work, then your ldap is probably set up right :) But you’ve already set up ldap properly before you stumbled this far, right?

Linux, howto, security howto, ldap, ldaps, lighttpd, mediawiki, mod_auth, server-config, ssl, wiki

Create some new directories:

Create a startup script for the random number generator in /etc/init.d

Create a startup script for sshd in /etc/init.d

Don’t forget to link them both in /etc/rc2.d so they’ll start automatically.  I used 50 and 99 to try to make sure that prngd starts before sshd fires up.

Create ssh public key pairs.  Don’t change these output names, the daemon expects them to be named like this and if you change them, you’ll see an error like no key found, ssh v1 not starting.  But who really cares, right?

Start the daemons and you should be good to go.  If you’re getting PRNGD not seeded errors, go take care of some other stuff, it will eventually stop as long as you installed prngd properly and started it up.  Generating the keys will probably take forever if you’re on an old Ultra 1 like me, give them a minute or two.  Entropy will take forever+1.  You can fill the seed files with garbage data if you want to speed it up.  If you’re still getting PRNGD errors an hour later, you could try the kernel patch to add /dev/random /dev/urandom support directly to the kernel.  (Sun patch 112438-03) I chose not to because I didn’t want to risk something going terribly wrong with this machine.  It’s unique in my environment and been shoved in a corner and forgotten about for a long time until now!

I also installed bash and top.  Bash was a no brainer!  I hate old ksh shells with broken backspaces, arrow keys, and lack of a command history.  They were both installed with pkgadd -d, no additional script writing or directory creating necessary.  If you have library issues after installed, run ldd on the binaries and do a google search to find what libraries packages you need.

Uncategorized ancient, bash, egd, gcc, popt, prngd, rsync, solaris, ssh, ssl, sun, sunfreeware, sunos, top, zlib

This doesn’t have to be complicated at all.  This was what I did on my ldap servers:

That’s it!  No messing with the CA.pl script or running multiple openssl commands for requests, signings, password stripping, and catting keys/crts together.  I tested my LDAP implementation like this and it worked like a charm.  Having a copy of both certificates located at /etc/openldap/cacerts/ on both machines worked for me.  When I set up clients, I put the certs in their cacerts directory and they work just fine with start tls.  If you’re doing this for an openldap implementation, you can make sure it’s working using “ldapsearch -x -ZZ” which requires your encryption to work.

http://blog.rootninja.com/wp-content/uploads/2008/09/rootninja_80×151.jpg“>http://blog.rootninja.com/wp-content/uploads/2008/09/rootninja_80×151.jpg” alt=”root|ninja” width=”80″ height=”15″ />

Linux cert, key, ldap, openldap, openssl, pki, self-signed certificate, ssl, tls