Make certificates quickly

Now that you have your own Certificate Authority setup from my previous article you’ll want a fast way of whipping up new certs. Never fear for making certs is here. Drop the following code into an executable file and place it into the myCA folder. You’ll be able to make certificates at whim by issuing a command like

make-cert.sh hostname.lan.domain.com 3650 01


#!/bin/bash

mkdir $HOSTNAME
openssl genrsa -des3 -out $HOSTNAME/$HOSTNAME.key 4096
openssl req -new -key $HOSTNAME/$HOSTNAME.key -out $HOSTNAME/$HOSTNAME.csr
openssl x509 -req -days $DAYS -in $HOSTNAME/$HOSTNAME.csr -CA cert/cert.pem -CAkey key/ca.key.pem -set_serial $SERIAL -out $HOSTNAME/$HOSTNAME.crt
openssl rsa -in $HOSTNAME/$HOSTNAME.key -out $HOSTNAME/$HOSTNAME.key.insecure
mv $HOSTNAME/$HOSTNAME.key $HOSTNAME/$HOSTNAME.key.secure
mv $HOSTNAME/$HOSTNAME.key.insecure $HOSTNAME/$HOSTNAME.key
exit 0


RADIUS Setup for OS X El Capitan – Server 5.x

Quite simple to setup. First paste in the following commands.

radiusconfig -setconfig auth yes
radiusconfig -setconfig auth_badpass yes

Now install an SSL cert/key pair for your host, the built in ones are found in /etc/certificates or you followed my previous article about becoming a certificate authority and you have the certs on hand.

radiusconfig -installcerts /path/to/key /path/to/cert


Now… if you didn’t make your own CA and you’re using the built in Apple Server certs then you’ll have to do some extra magicary. First use pull an ls /etc/certificates and not the key, cert, and chain files for your host.


radiusconfig -installcerts /path/to/key.pem /path/to/cert.pem /path/to/chain.pem
radiusconfig -setcertpassword
Apple:UseCertAdmin


The last line is the ‘magic’ that I spoke of earlier.

Finally add some clients

radiusconfig -addclient other

Then start the radius server

serveradmin start radius


When I did this recently I didn’t have a way to test the server so I installed the FreeRadius server via brew.

brew install freeradius-server

And then tested the server by using radtest The binary can be found in the following directory /usr/local/Cellar/freeradius-server/3.0.9/bin

The syntax of the command is as follows:

radtest username password radius-server[:port] nas-port-number secret

Here’s an example:

radtest username password 192.168.1.1 10 secret


An Access-Accept is a passing grade!

Mac OS X Server 5.x El Capitan SSL Certificate Authority

I use Open Directory a lot, I can’t think of many times when I don’t use it at least once a day in some way whether that be direct or indirect. It’s not the best directory system out there – hell, it’s not even very good but it’s what the fine people at Apple have supplied us with and it’s what I use. Although I have long had a pet peeve with the way OD is built if you just run through the setup wizard. The certificate expires in one year. Almost every time I encounter an OD server in the wild nine times out of ten the certs are a mess. They’re either expired or about to expire and all the services that depend on them are freaking out. The clients are constantly being prompted to accept an invalid cert and OD fail-over tends to stop working. My solution has been to build a certificate authority for all my OD installs and to build my own certs that are valid for ten years, that way I won’t have to worry about them expiring and let’s be honest there’s no Mac server on the planet that’s going to last ten years lol (sense the cynicism yet?)

Create the Root Key

First we’re going to hop into a terminal on any Mac OS X box and navigate to somewhere safe in the file system and build the master key, make sure the password you use for this is kept secret and safe.

cd /some/where/safe/I/dont/care/where
mkdir -p myCA/cert myCA/key
cd myCA
openssl genrsa -aes256 -out key/ca.key.pem 4096
chmod 400 key/ca.key.pem


That OpenSSL command is going to ask you a bunch of questions, answer them to the best way you see fit and for the common name put the organization that you’re building this certificate authority for. Do not put an actual domain. Record what you wrote for Common Name because we’re going to need it later. Whitespaces are allowed. Oh and one more pro tip, make sure the value of the certificate common is unique and can’t be half-matched. For example I made a root cert called “Client Name” but when it came to do deploy the certificate via munki, the check install script found a cert called “Client Name Open Directory” and thus the command matched and wouldn’t deploy the new root cert.

Create the Root Cert


openssl req -key key/ca.key.pem -new -x509 -days 3650 -sha256 -extensions v3_ca -out cert/cert.pem
chmod 444 cert/cert.pem


Now we have two files.

cert/cert.pem – This is your CA’s certificate and can be publicly available and of course world readable. You will need to load this certificate into all the clients in your network.

key/ca.key.pem – This is your CA’s private key. Although it is protected with a passphrase you should restrict access to it, so that only root can read it.

Create the First Server key/cert combo

We can now start creating SSL certificates for our various servers and services. Create a directory named a hostname corresponding to the hostname for the computer or service you are creating the certificate for.

Create the first key

openssl genrsa -aes256 -out hostname/hostname.domainname.key 4096

While answering the questions for this make sure you type in the FQDN for server or service you want to secure into Common Name.

Create the server cert

openssl req -new -key hostname/hostname.domainname.key -out hostname/hostname.domainname.csr

Sign the cert

openssl x509 -req -days 3650 -in hostname/hostname.domainname.csr -CA cert/cert.pem -CAkey key/ca.key.pem -set_serial 01 -out hostname/hostname.domainname.crt

Now before we continue I have to drill into you that it’s imperative that you document these certs as you make them, which hosts they’re deployed on to, and what the serial number is. It will help you in the long run.

Finally we’re going to make a passwordless version of the server key, this is the key that we’ll ultimately use on our server. We need a passwordless key so that the Mac OS X services do not need human intervention when trying to use the certs. Otherwise you’ll have to type the cert password in every time you restart the service.


openssl rsa -in hostname/hostname.domainname.key -out hostname/hostname.domainname.key.insecure
mv hostname/hostname.domainname.key hostname/hostname.domainname.key.secure
mv hostname/hostname.domainname.key.insecure hostname/hostname.domainname.key


Import the CA and Cert

Copy the myCA/cert.pem, hostname/hostname.domainname.key, and hostname/hostname.domainname.crt files to your Mac OS X server. Double click on the myCA/cert.pem, this should open the file with Keychain Access which will ask you which keychain to import the cert to. Select the system keychain and then double click on the entry in Keychain Access and set the trust setting to Always Trust.

Next open Server.app and click on Certificates. Click on the gear menu and select Import Certificate Identity. Drag in the hostname/hostname.domainname.key, and hostname/hostname.domainname.crt files, when you do this you should see that the files are signed by the organization that you entered in step one. Finally select the cert from the list of certs in server.app and give it time to switch over.

Finally fire up the wiki service in server.app, whip open your browser of choice and connect to the FQDN that you create the SSL cert for. Remember, if your cert common name doesn’t match the way you address the wiki in the URL bar you will get a hostname mismatch error. You MUST make sure the names match from what you type into the certificate’s common name and how you connect to the wiki.

Root Cert Deployment

So now maybe you want to be able to use this cert with some of your clients right? You can do this a multitude of ways. Such as:

Copy the file to /tmp across your network and run the following command as root


security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "/tmp/cert.pem"; srm "/tmp/cert.pem"


Or if you’re cool you’ll use some sort of package deployment system. I use munki because it’s not backed by some money hungry corporation. Here’s looking at you Cohen. 😉 To do this I made a new package with Composer dropped my root cert into /tmp and then wrapped then finished the Composer wizard. Import this package into munki using munkiimport and then drop aforementioned command into post-install script.

For extra bonus points it would be cool to see if the root cert is installed before we go pushing this package to all the workstations in the network. To do this I added a little check install script to munki. Note that you have change the -c flag to match whatever you wrote for the root cert common name way back in step one.


#!/bin/bash

if [ $? != 0 ]; then
exit 0
else
exit 1
fi


You’ll note that the exit codes are reversed here, it’s because Munki will only install if the check install script exits on 0 which is how our security check command will exit if it finds the cert installed. So we flip the exit code to make munki do our bidding.

At this point you should be feeling like a rock star for the following reasons:

• You haven’t given Go Daddy any money
• You’ve successfully built and deployed your own cert authority
• You won’t have to worry about onboarding new machines with the cert cause you’ve got in munki

Open Directory Crashing from Wildcard SSL Certificate

I encountered an issue recently where I imported a wildcard certificate into an Open Directory server which was fine however once I tried to select it Open Directory immediately stopped working.


2015-03-14 10:42:07.113 AM com.apple.launchd[1]: (org.openldap.slapd[20606]) Exited with code: 1
2015-03-14 10:42:07.113 AM com.apple.launchd[1]: (org.openldap.slapd) Throttling respawn: Will start in 10 seconds
2015-03-14 10:42:17.150 AM com.apple.launchd[1]: (org.openldap.slapd[20612]) Exited with code: 1
2015-03-14 10:42:17.150 AM com.apple.launchd[1]: (org.openldap.slapd) Throttling respawn: Will start in 10 seconds


To diagnose I turned ldap off by way of launchd

sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist

And then told openldap to launch in debug mode and don’t fork.

sudo /usr/libexec/slapd -d 99 -F /etc/openldap/slapd.d/

To which I received this reply:

TLS: attempting to read `/etc/certificates/server.inside.tld.ca.6C66FD3E997A9FD902DEA9050EE3F9A58EF63742.key.pem'.
TLS: could not use key file `/etc/certificates/server.inside.tld.ca.6C66FD3E997A9FD902DEA9050EE3F9A58EF63742.key.pem'.
TLS: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch /SourceCache/OpenSSL098/OpenSSL098-47.2/src/crypto/x509/x509_cmp.c:406
55047382 main: TLS init def ctx failed: -1

That’s strange I thought, so I cracked open /etc/openldap/slapd.d/cn=config.ldif in vim and found that at the bottom of the file the cert and the key did not change over properly.

olcTLSCertificateKeyFile: /etc/certificates/server.inside.tld.ca.6C66FD3E997A9F
D902DEA9050EE3F9A58EF63742.key.pem
olcTLSCertificatePassphrase: "Mac OS X Server certificate management.6C66FD3E9
97A9FD902DEA9050EE3F9A58EF63742"
olcTLSCertificateFile: /etc/certificates/*.inside.tld.ca.8597F1FABB98A20805065
751BA49E3076EF84E60.cert.pem
olcTLSCACertificateFile: /etc/certificates/*.inside.tld.ca.8597F1FABB98A208050
65751BA49E3076EF84E60.chain.pem

Notice how the certkeyfile does not match the cert or chain file? It’s like Server.app b0rk3d on parse the wildcard symbol while modifying this file. The only way I’ve figured out how to get OD back on it’s feet after this disaster is to remove these lines from the cn=config.ldif and rebooting the OD server. Even if I tried hand coding the cert in Open Directory will stop crashing however the secure LDAP service does not come up.

I’ve since switched to an internal CA and making certs for each FQDN which has been a way better experience.

Snow Leopard SSL Certificate Authority

As more services are introduced into your network and thus the more users you have, the need for security goes up. Maintaining your own certificate authority is a simple and free way to ensure the highest level of security while not breaking the bank.

1. Create the Certificate Authority

First we’re going to hop into a terminal on any Mac OS X Server box and navigate to `/etc/certificates` and create some directories

cd /etc/certificates/
sudo mkdir -p myCA/cert myCA/key
cd myCA


We need to create the CA signing certificate and key. After executing the first command you will be asked a series of questions. Enter them as needed.


homer:myCA jordan$ sudo openssl req -new -x509 -keyout key/myca.key -out cert/myca.crt -days 3650
Generating a 1024 bit RSA private key
.....++++++
............................................................++++++
writing new private key to 'key/myca.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:BC
Locality Name (eg, city) []:Vancouver
Organization Name (eg, company) [Internet Widgits Pty Ltd]:YAweb2.0CA LTD
Organizational Unit Name (eg, section) []:DevOps
Common Name (eg, YOUR name) []:yaweb20ca.ca
Email Address []:systems@yaweb20ca.ca


Two files are created:


chmod 0400 /etc/certificates/myCA/key/myca.key


2. Create the Server Key

Next, go up one level to `/etc/certificates` We can now start creating SSL certificates for our various servers and services. Create a directory named hostname.domainname corresponding to the hostname for the computer or service you are creating the certificate for and enter the directory.

Next up on the list is to create a key that corresponds to our server. We will do that with this command:

openssl genrsa -des3 -out hostname.domainname.key 4096

Again, those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later. Don’t forget to store the password somewhere safe, I suggest creating a new keychain on your Mac OS X server box.

Now, we have to create a signing request, or CSR, from the server key we just made. This signing request will usually make a trip to a genuine Certificate Authority to have the key signed and a real, verified, bonafide signed certificate returned back to us. So, to generate our signed certificate, we’ll need to first have a signing request so we can make the signed cert. See how that works?

3. Create a Certificate Signing Request

To create the CSR, we do this:

openssl req -new -key hostname.domainname.key -out hostname.domainname.csr

Now remember, kids. This is the part where we do put in our actual real information because the server does in fact belong to us. Put in the real domain where it says “Common Name (eg, YOUR name) []:”. Fill out everything correctly. So for a wildcard cert enter, *.top.level.domain

4. Sign the Certificate

Now, we are going to take all these files and make them do some voodoo. We are going to sign the signing request using the Certificate Authority certificate and key that we made at the beginning. What we will get is our perfectly forged signed certificate. OK, not perfectly, because we are not a real CA. But we’ll get a pretty darn good signed cert that will work for us rather nicely and be valid for 10 years! What value!

The command we’re going to run looks like this:

openssl x509 -req -days 3650 -in hostname..csr -CA ../myCA/myCA.crt -CAkey ../myCA/myCA.key -set_serial XX -out hostname.domainname.crt

It will ask you for the password for the myCA.key file. Which is referenced at the top of this article. The set_serial switch is a two digit value to denote the certificate serial number. Every certificate you sign from this CA must have a unique serial number.

5. Create a Passwordless Certificate

Now, we have a little problem. Our hostname.key file will cause apache2 to prompt us for a password every time it starts. We need to fix it so that doesn’t happen. We’ll do that with these three commands:

openssl rsa -in .domainname.key -out .domainname.key.insecure
* Enter the password that you entered when creating this key
mv hostname..key hostname.domainname.key.secure
mv hostname.domainname.key.insecure hostname.domainname.key


Then set permissions for the files

chmod 0600 hostname.key.secure hostname.key hostname.csr hostname.crt


6. Outcome

The final list of files and their purpose is as follows:

drwxr-xr-x 2 root root 4096 2008-06-02 13:54 .
drwx------ 10 root root 4096 2008-06-02 13:35 ..
-rw-r--r-- 1 root root 2049 2009-04-02 13:32 hostname.tld.crt [our server certificate]
-rw-r--r-- 1 root root 1748 2009-04-02 13:23 hostname.tld.csr [our server signing request]
-rw-r--r-- 1 root root 3243 2009-04-02 13:54 hostname.tld.key [our password-less server key]
-rw-r--r-- 1 root root 3311 2009-04-02 13:13 hostname.tld.key.secure [our passworded server key]


7. Don’t Forget

Don’t forget to load the myCA.crt file into your various Mac clients. This will allow the computer to verify the identity of the SSL certificates to the end user, mitigating the risk of a MITM (man in the middle) attack. To do so simply copy the file to all your workstations and double click the cert. Keychain manager should load and ask what security setting you would like, select Always Trust.