Next: , Previous: Issuing CRLs, Up: Top


3.4 Application requirements

Application place different requirements on certificates. This section tries to expand what they are and how to use hxtool to generate certificates for those services.

3.4.1 HTTPS - server

     hxtool issue-certificate \
     	  --subject="CN=www.test.h5l.se,DC=test,DC=h5l,DC=se" \
     	  --type="https-server" \
               --hostname="www.test.h5l.se" \
               --hostname="www2.test.h5l.se" \
               ...

3.4.2 HTTPS - client

     hxtool issue-certificate \
     	  --subject="UID=testus,DC=test,DC=h5l,DC=se" \
     	  --type="https-client" \
               ...

3.4.3 S/MIME - email

There are two things that should be set in S/MIME certificates, one or more email addresses and an extended eku usage (EKU), emailProtection.

The email address format used in S/MIME certificates is defined in RFC2822, section 3.4.1 and it should be an “addr-spec”.

There are two ways to specifify email address in certificates. The old way is in the subject distinguished name, this should not be used. The new way is using a Subject Alternative Name (SAN).

Even though the email address is stored in certificates, they don't need to be, email reader programs are required to accept certificates that doesn't have either of the two methods of storing email in certificates – in which case, the email client will try to protect the user by printing the name of the certificate instead.

S/MIME certificate can be used in another special way. They can be issued with a NULL subject distinguished name plus the email in SAN, this is a valid certificate. This is used when you wont want to share more information then you need to.

hx509 issue-certificate supports adding the email SAN to certificate by using the –email option, –email also gives an implicit emailProtection eku. If you want to create an certificate without an email address, the option –type=email will add the emailProtection EKU.

     hxtool issue-certificate \
     	  --subject="UID=testus-email,DC=test,DC=h5l,DC=se" \
     	  --type=email \
     	  --email="testus@test.h5l.se" \
               ...

An example of an certificate without and subject distinguished name with an email address in a SAN.

     hxtool issue-certificate \
     	  --subject="" \
     	  --type=email \
     	  --email="testus@test.h5l.se" \
               ...

3.4.4 PK-INIT

A PK-INIT infrastructure allows users and services to pick up kerberos credentials (tickets) based on their certificate. This, for example, allows users to authenticate to their desktops using smartcards while acquiring kerberos tickets in the process.

As an example, an office network which offers centrally controlled desktop logins, mail, messaging (xmpp) and openafs would give users single sign-on facilities via smartcard based logins. Once the kerberos ticket has been acquired, all kerberized services would immediately become accessible based on deployed security policies.

Let's go over the process of initializing a demo PK-INIT framework:

     hxtool issue-certificate \
             --type="pkinit-kdc" \
             --pk-init-principal="krbtgt/TEST.H5L.SE@TEST.H5L.SE" \
             --hostname=kerberos.test.h5l.se \
             --ca-certificate="FILE:ca.pem,ca.key" \
             --generate-key=rsa \
             --certificate="FILE:kdc.pem" \
             --subject="cn=kdc"

How to create a certificate for a user.

     hxtool issue-certificate \
             --type="pkinit-client" \
             --pk-init-principal="user@TEST.H5L.SE" \
             --ca-certificate="FILE:ca.pem,ca.key" \
             --generate-key=rsa \
             --subject="cn=Test User" \
             --certificate="FILE:user.pem"

The –type field can be specified multiple times. The same certificate can hence house extensions for both pkinit-client as well as S/MIME.

To use the PKCS11 module, please see the section: see How to use the PKCS11 module.

More about how to configure the KDC, see the documentation in the Heimdal manual to set up the KDC.

3.4.5 XMPP/Jabber

The jabber server certificate should have a dNSname that is the same as the user entered into the application, not the same as the host name of the machine.

     hxtool issue-certificate \
     	  --subject="CN=xmpp1.test.h5l.se,DC=test,DC=h5l,DC=se" \
               --hostname="xmpp1.test.h5l.se" \
               --hostname="test.h5l.se" \
               ...

The certificate may also contain a jabber identifier (JID) that, if the receiver allows it, authorises the server or client to use that JID.

When storing a JID inside the certificate, both for server and client, it's stored inside a UTF8String within an otherName entity inside the subjectAltName, using the OID id-on-xmppAddr (1.3.6.1.5.5.7.8.5).

To read more about the requirements, see RFC3920, Extensible Messaging and Presence Protocol (XMPP): Core.

hxtool issue-certificate have support to add jid to the certificate using the option --jid.

     hxtool issue-certificate \
     	  --subject="CN=Love,DC=test,DC=h5l,DC=se" \
               --jid="lha@test.h5l.se" \
               ...