IKEMAN(1)

NAME
ikeman - manage certificates for iked(8)

SYNOPSIS
ikeman [directory]

DESCRIPTION
ikeman allows the user to display, revoke and sign certificates for iked(8) or isakmpd(8) in a screen-oriented fashion using the curses(3) screen display library.

ikeman loads all certificate authorities (CAs) from subdirectory ca/, all certificate revocation lists (CRLs) from crls/ and all certificates from certs/. It tries to connect certificates and CRLs to their respective CA and thus provide the user a hierarchical view of this data found on his system. ikeman can also create new CAs, load and sign certificate signing requests (CSRs), and easily revoke certificates by creating CRLs.

While ikeman is running, the screen is divided into three windows. The left one shows all CAs found, showing the user a preview of CRLs and certificates it matched to them. In the top (CA view) window the user selects objects for detailed information in the bottom window.

ikeman is controlled mostly by arrow keys, while pressing q quits the program. The keys h, j, k, l and G have the same function as in vi(1). All passwords are read directly from /dev/tty, using readpassphrase(3).

ikeman may cease operation when the screen size is insufficient for display. The user will be given notice.

The options are as follows:

directory
    The directory argument specifies the base directory where ikeman searches for all the data in its respective subdirectories. It defaults to /etc/iked/.

CREATING A NEW CERTIFICATE AUTHORITY
After selecting the “NEW CA” option in the left menu, you will be asked series of questions about your new CA. The password must not be empty and should be longer than 4 characters, as the openssl(1) utility won't let you decrypt and use the key otherwise.

The “canonical name” (CN) field in the certificate subject name is mandatory and must not be ommited. ikeman will try to save all the information to the directory /etc/ssl/CommonName, but will ask for other path on failure. ikeman creates a subdirectory named accordingly.

Make sure the destination is well protected against even short periods of unauthorized access, as the CA key is the most critical part of your new PKI. The permissions are set appropriately (0400 for the key file).

After you've created a new CA, it will display in the list of CAs for you to work with, but you will have to copy its files to appropriate directories in order to be loaded next time.

CERTIFICATE REVOCATION PROCESS
You can change the revocation status of a certificate by pressing the r key. It will be marked as changed and the CA will be marked as “dirty”. After you've done your changes, select the “GENERATE NEW CRL” option. You will have to provide read access, path and password to your CA key. The created CRL will be loaded next time you run ikeman ( provided that you copied it to the crls/ directory).

The openssl(1) utility creates CRLs according to the content of a plain-text “index file”, which contains the revoked serial number, date of the revocation and date of its expiration (which should the user never rely on, as it's generally used very seldom), along with some other information. Furthermore, the user is required to maintain an openssl.cnf file containing records of all his CAs and location of their files.

ikeman uses different approach; whenever it generates CRL, it copies the newest revocation list it loaded, with user changes applied, to a new CRL file. This way you have only one CRL to use, releasing you from the complexity of maintaing multiple files with multiple (possibly contradictory) records. Moreover, the openssl(1) tool handles this in a wrong way - see CAVEATS.

SIGNING A CERTIFICATE REQUEST (CSR)
To create a CSR on a new host, you can use this command:

    # openssl req -new -key <private-key> -out <csr-target>

and then copy the “csr-target” file over a secure channel for the authority to sign it, by selecting “ADD CERT BY SIGNING CSR” option.

You will have to provide read access, path and password to your CA key.

The exact type of X.509v3 Subect Alternative Name, which is used (for example) by isakmpd.policy(5), is recognized automatically from user input; it is either IPv4 address, IPv6 address, Fully Qualified Domain Name or User FQDN. The field is mandatory here.

After you've signed a new certificate, it will display under its CA for you to see, but you will have to copy it to the certs/ directory in order to be loaded next time (if you didn't save it there right away).

FILES
/etc/iked/
    iked(8) configuration.
/etc/isakmpd/
    isakmpd(8) configuration.

SEE ALSO
ikectl(8), iked(8), ipsec(4), ipsec.conf(5), isakmpd(8), isakmpd.conf(5), isakmpd.policy(5), openssl(1), ssl(8)

AUTHORS
The ikeman program was written by Martin Pelikan.

BUGS
ikeman does not support CRL v2 Extensions, such as “reason” why a particular certificate was revoked.

Also, ikeman implements a very specific and limited subset of what certificates might contain, because of its limited purpose of accompanying isakmpd(8) and iked(8). This might change in the future.

Note that ikeman doesn't care if a file in ca/ doesn't have the issuer and the subject name equal, neither does it care if a self-signed certificate appears in certs/.

CAVEATS
Be aware that as of OpenBSD 4.9 isakmpd(8) does not block connections initiated by clients with revoked certificates. The appropriate patch can be found at http://marc.info/?l=openbsd-tech&m=129460973416515&w=2

Also, some IPsec implementations have troubles working with keys larger than 4096 bits.

The openssl(1) tool's verify command treats multiple CRLs this way:

1.  Calculate a hash of the issuer's name; you can do so by executing:

        # openssl x509 -in <ca-cert> -noout -hash

2.  Load all files <hash>.rN, where N is a positive integer >= 0.

3.  Look at the first ( <hash>.r0) and check only that one, no matter what the others are.

ikeman finds for each CA the newest CRL and verifies all certificates only against that one. Note that this behavior might change with the support for CRL v2 extensions.