The tool itself will perform the commands on the host system through normal openssl command lines and therefore maintains full compatibility with OpenSSL itself. If something goes wrong or you need something done manually you can still issue the proper commands.

The pyPKI front-end has the following features and capabilities:
* Request new client or server certificate
* Perform bulk requests based on csv import file
* Revoke certificates
* Generate Certificate Revocation Lists
* Create reports on certificate expiration
* Reads most configuration settings from openssl.cnf such as Certification Authorities, default CSR parameters and more. See this blog post for instructions how to implement the basic filesystem structure for use with pyPKI
* Supports the use of Yubikey Neo with PIV applet to store the CA private key(s). See this blog post for instructions how to implement the Yubikey Neo to store your private keys.

You can download the pyPKI application here. Or by issuing:

git clone https://dverslegers@bitbucket.org/dverslegers/pypki.git

The installation instructions can be found in the readme.pdf located in the root directory.

Some screenshots of the application:

In this short how-to guide we will establish a Public Key Infrastructure based on OpenSSL. To keep things simple and straight forward we only define two levels (although many more are possible):
- A Root Certification Authority which is only used to sign certificates of subordinate intermediary Certification Authorities
- An Intermediary Certificate Authority which is used to issue certificates for both servers and users

It should however be easy to modify the instructions below to your target implementation.

Creating a dedicated user for pki operations

For security reasons it is preferable to create a dedicated user for use with your PKI and to ensure that only this user (or group of users) has access to this location. In our setup we will create a user called pki and use the homedirectory for this account as root for the PKI.

sudo adduser pki
chmod -R 0700 /home/pki/pki-root

Make sure you repeat the last command when the PKI setup is completed to ensure that no files or directories remain world readable.

A word about structure

The following directory structure is recommended as a skeleton for setting up a new PKI. Each Certificate Authority in your Public Key Infrastructure should have a directory structure similar to the one explained below.

PKI directory: Root directory for the OpenSSL PKI
CA directory : Root directory for the Certificate Authority
CA.db.tmp: Temporary directory for openssl operations. This directory will mainly be used to store intermediary .pem files.
CA.db.certs: Directory used to store generated certificates in .pem format. It is advised to create additional subdirectories corresponding to the common name of the generated certificate to hold certificates, private keys and other formats such as p12 containers for future reference.
CA.db.crl: Directory used to store certificate revocation lists generated by openssl.

Additionally the following files will need to be created for the CA to function properly.

CA.db.serial: File indicating serial to be used for the next generated certificate. The initial value should be 01.
CA.db.crlserial: File indicating serial to be used for the next CRL. The initial value should be 01.
CA.db.index: Text based database file used by OpenSSL to store details of all generated certificates. Initially this file should be empty.
CA.db.rand: File containing a random string which ensures the randomness of the CA. If security is of high importance it is recommended to use a hardware random key generator for this.

To simplify our setup we will consistently use the following naming and extension convention throughout our PKI:
.crt: File containing a certificate
.csr: File containing a Certificate Signing Request
.key: File containing a private key
.p12: Binary container with certificate, private key and ca chain
.pwd: File containing the password used to open the p12 container

The commands to put the above mentioned structure in place are mentioned below. Make sure you modify ca in the example to reflect the name of the CA you are putting in place and make sure you execute the commands within the proper location on the filesystem (in this example /home/pki/pki-root).

mkdir ca
mkdir ca/ca.db.tmp
mkdir ca/ca.db.certs
mkdir ca/ca.db.crl
echo 01 > ca/ca.db.serial
echo 01 > ca/ca.db.crlserial
touch ca/ca.db.index
openssl rand -out ca/ca.db.rand 8192

Configure OpenSSL through openssl.cnf

The OpenSSL configuration file allows us to (pre-)define many of the settings related to our Certificate authority. Although many of these options can equally be set using command line parameters we can simplify our command lines and standardise the creation of certificates by using the configuration file.

We will define the following aspects of our Certification Authority through the configuration file:
- The Certification Authorities making up our Public Key Infrastructure and their related settings such as base directories and files.
- The policies to be applied to certificate requests, indicating which fields are optional, mandatory and/or should match the Certification Authorities values.
- The standard certificate request parameters to be used.
- The extensions to be used when generating specific types of certificates.

Let us create the OpenSSL file and place it in our root PKI directory (/home/pki/). The OpenSSL configuration file should start with a entry indicating which Certification Authority should be used by default is none is specified during certificate generation.

[ ca ]
default_ca  = CA        # The default ca section

As a next step we need to introduce a CA configuration section for each of the CA’s which make up our Public Key Infrastructure.

Note: if your PKI only consists of one CA you should only create one section.
Note: Make sure to replace CA with the name of the Certification Authority you are implementing, in our example RootCA and IntermCA.

[ CA ]

dir     = ./CA            
# Where everything is kept
certs       = $dir/ca.db.certs      
# Where the issued certs are kept
crl_dir = $dir/ca.db.crl         
# Where the issued crl are kept
database    = $dir/ca.db.index     
# database index file.
unique_subject = no           
# Set to 'no' to allow creation of several ctificates with same subject.
new_certs_dir   = $dir/ca.db.certs 
# default place for new certs.
certificate = $dir/ca.crt   
# The CA certificate
serial      = $dir/ca.db.serial     
# The current serial number
crlnumber   = $dir/ca.db.crlserial  
# the current crl number must be commented out to leave a V1 CRL
private_key = $dir/ca.key             
# The private key
RANDFILE    = $dir/ca.db.rand        
# private random number file
name_opt    = ca_default        
# Subject Name options
cert_opt    = ca_default        
# Certificate field options

default_days    = 365           
# how long to certify for
default_crl_days  = 60          
# how long before next CRL
default_md  = md5       
# use public key default MD
preserve    = no            
# keep passed DN ordering

policy          = policy_match

The options, policy match and unique subject are most commonly used for root certification authorities since you will want the attributes of the intermediary CA’s to match the root CA and to ensure that you have a unique subject. These two options should potentially be modified for intermediary CA’s.

Make sure to modify the relevant values to reflect the configuration of the CA’s you want to put in place. Additionally it is advisable to modify the default_ca parameter to contain the CA you want to use for signing certificates by default.

Once we defined the CA’s we have the option of creating a policy which will be applied to certificate signing requests. By default the OpenSSL configuration file contains two policies called policy_match and policy_anything.
The first requires the request to match most of the values present in the CA certificate such as country name, state or province etc.
The latter imposes no restrictions on the content of the certificate signing request.

[ policy_match ]
countryName     = match
stateOrProvinceName = match
localityName            = optional 
organizationName    = optional
organizationalUnitName  = optional
commonName      = supplied
emailAddress        = optional

[ policy_anything ]
countryName     = optional
stateOrProvinceName = optional
localityName        = optional
organizationName    = optional
organizationalUnitName  = optional
commonName      = supplied
emailAddress        = optional

Let’s go ahead and define our own policy which is to be used when signing user certificates. Feel free to modify the template below to match whatever requirements you want to put on specific types of certificate signing requests.

[ policy_usr ]
countryName     = supplied
stateOrProvinceName = supplied
localityName        = supplied
organizationName    = supplied
organizationalUnitName  = optional
commonName      = supplied
emailAddress        = supplied

With our CA’s and policies in place it’s time to define the ‘default’ request parameters. Modify the parameters below to reflect your organisation

[ req ]
default_bits        = 2048
default_keyfile     = privkey.pem
distinguished_name  = req_distinguished_name
attributes      = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = nombstr

[ req_distinguished_name ]
countryName         = Country Name (2 letter code)
countryName_default     = BE
countryName_min         = 2
countryName_max         = 2

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = Vlaams-Brabant

localityName            = Locality Name (eg, city)
localityName_default        = Leuven

0.organizationName      = Organization Name (eg, company)
0.organizationName_default  = AUSY

1.organizationName      = Second Organization Name (eg, company)
1.organizationName_default  = not used

organizationalUnitName      = Organizational Unit Name (eg, section)
organizationalUnitName_default  = Demo CA project

commonName          = Common Name (eg, YOUR name)
commonName_max          = 64

emailAddress            = Email Address
emailAddress_max        = 64

[ req_attributes ]
# challengePassword     = A challenge password
# challengePassword_min     = 4
# challengePassword_max     = 20

# unstructuredName      = An optional company name

As a final step we have the option of defining specific extensions, contstraints and comments for specific certificate types. Below you find an example of server and user certificate types and their specifics. Make sure to modify the crlDistributionPoints and/or comment to reflect your environment.

[ srv_cert ]
basicConstraints=CA:FALSE
nsCertType            = server
crlDistributionPoints = URI:http://example.com/crl.pem
nsComment           = "OpenSSL Generated Server Certificate"

[ usr_cert ]
basicConstraints=CA:FALSE
nsCertType = client, email
nsComment           = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

The v3req, v3ca and crlext definitions are required for OpenSSL to function properly. These sections define the basic configuration for a common certificate request and the required extensions to generate a CA certificate. The crlext section defines how CRL’s are generated.

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]
# Extensions for a typical CA
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true

[ crl_ext ]
# CRL extensions.
authorityKeyIdentifier=keyid:always,issuer:always

## Establishing our CA’s
### Setup Root CA

Create Root CA public / private keypair

openssl genrsa -des3 -out ./RootCA/RootCA.key 2048

Generate Root CA certificate, which is by definition a self signed certificate. Don’t forget to modify the validity to an appropriate value.

openssl req -new -x509 -days 3650 -key ./RootCA/RootCA.key -out ./RootCA/RootCA.crt -config openssl.cnf


Setup intermediary CA(’s)

Create Intermediate CA public / private keypair

mkdir ./RootCA/RootCA.db.certs/IntermCA
openssl genrsa -des3 -out ./RootCA/RootCA.db.certs/IntermCA/IntermCA.key 2048


Generate Certificate Siging Request for intermediary CA. Don’t forget to modify the validity to an appropriate value.

openssl req -new -days 1095 -key ./RootCA/RootCA.db.certs/IntermCA/IntermCA.key -out ./RootCA/RootCA.db.certs/IntermCA/IntermCA.csr -config openssl.cnf

Sign the previously generated CSR using the RootCA while adding the CA extension to ensure that the resulting certificate can be used to sign other certificates.

openssl ca -config openssl.cnf -name RootCA -extensions v3_ca -out ./RootCA/RootCA.db.certs/IntermCA/IntermCA.crt -infiles ./RootCA/RootCA.db.certs/IntermCA/IntermCA.csr

Now copy over the relevant certificate and key to the IntermCA root.

cp ./RootCA/RootCA.db.certs/IntermCA/IntermCA.crt ./RootCA/RootCA.db.certs/IntermCA/IntermCA.key ./IntermCA/


It’s recommended to create a certificate chain file for future use. This file can be imported by a client and will indicate the full chain of Certification Authorities linked to the provided certificate.

Common operations

That’s it, all relevant bits and pieces should be in place to start using our OpenSSL PKI. In this section you will find some common operations and the related openssl commands.

Generate server certificate

openssl req -newkey rsa:2048 -keyout ./IntermCA/IntermCA.db.certs/server.domain/server.domain.key -nodes -config openssl.cnf -out ./IntermCA/IntermCA.db.certs/server.domain/server.domain.csr
openssl ca -config openssl.cnf -name IntermCA -out ./IntermCA/IntermCA.db.certs/server.domain/server.domain.crt -infiles ./IntermCA/IntermCA.db.certs/server.domain/server.domain.csr


Generate user certificate

openssl req -newkey rsa:2048 -keyout ./IntermCA/IntermCA.db.certs/username/username.key -nodes -config openssl.cnf -out ./IntermCA/IntermCA.db.certs/username/username.csr
'' openssl ca -config openssl.cnf -extensions usr_cert -name IntermCA -out ./IntermCA/IntermCA.db.certs/username/username.crt -infiles ./IntermCA/IntermCA.db.certs/username/username.csr


Generate p12

openssl pkcs12 -export -clcerts -in ./IntermCA/IntermCA.db.certs/server.domain/server.domain.crt -inkey ./IntermCA/IntermCA.db.certs/server.domain/server.domain.key -certfile ./pki.crt -out ./IntermCA/IntermCA.db.certs/server.domain/server.domain.p12


Revoke certificate

openssl ca -config openssl.cnf -name IntermCA -revoke ./IntermCA/IntermCA.db.certs/02.pem


Generate CRL

openssl ca -config openssl.cnf -name IntermCA -gencrl -out ./IntermCA/IntermCA.crl/crl-27.02.2014.pem


Generate CA chain

cat ./RootCA/RootCA.crt ./IntermCA/IntermCA.crt > pki.crt


All the information you find here is already out there on the web, I just decided to put everything together in this post to avoid searching for bits and pieces of the solution.

Assumptions

• You already have an OpenSSL based certification authority in place for which you have previously generated a certificate and key pair. The CA's certificate and key pair is available in the form of a p12 container. Alternatively you could also choose the route of generating the private key directly on the Neo and then creating the CA certificate form there. Although this is a 'more secure' approach from security point of view it's not recommendable for this specific use case since you might want to recover or duplicate your private key in case the Yubikey Neo dies on you. This is only possible if you generate the private key outside of the Yubikey and then import it later on.

• You have a Yubikey Neo with the PIV applet preloaded at your disposal

Configuring Yubikey Neo for smart card (CCID) interface support

Recently yubico released a gui application called neo-manager allowing you to configure the neo. The current version (0.1.0) can be downloaded from here .

For common use it is recommended to configure the Yubikey Neo to use the HID + CCID with touch eject mode. This allows the Neo to act as a smart card (CCID) and OTP simultaneously. It does so by acting as a smart card whenever it is connected to a system, unless the button is pushed. In this case it will eject the smartcard, act as a regular yubikey OTP and after that insert the smartcard again.

For our specific purpose we could configure Neo to act only as a smart card (CCID) because we don't want to use our yubikey for anything other then (securely) storing the Certification Authority private key.

Getting our system to see neo as a smartcard

With the yubikey neo configured to act as a CCID device we need to get our system to interface with it. In my setup I will be using an Ubuntu Server 14.04 64bit system running inside of a VMWare Fusion virtual machine (USB 2.0 compatibility) for testing purposes, the steps required to get this to work on other Linux or OS X systems should be fairly similar.

We start by installing the opensc package on our system which contains the tools and drivers we need to get our yubikey piv up and running.

dennisverslegers@ubuntu:~$ apt-get install opensc

Now let's test if we can access our yubikey neo using opensc:

dennisverslegers@ubuntu:~$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             Yubico Yubikey NEO CCID 00 00

Assuming everything went well you should see the Yubikey Neo listed as a detected card reader. Check your version of opensc if this is not the case, we are running version 0.13

dennisverslegers@ubuntu:~$ opensc-tool -i
opensc 0.13.0 [gcc  4.8.2]
Enabled features: zlib readline openssl pcsc(libpcsclite.so.1)

Before we continue we should make sure that the Yubikey is not only detected as a reader but also as a smart card:

dennisverslegers@ubuntu:~$ opensc-tool --reader 0 --name
PIV-II card

We should now be able to list the contents of the PIV applet which should be, for the time being, empty.

dennisverslegers@ubuntu:~$ pkcs15-tool --list-data-objects
Using reader with a card: Yubico Yubikey NEO CCID 00 00
Data object 'Card Capability Container'
    applicationName: Card Capability Container
    applicationOID:  2.16.840.1.101.3.7.1.219.0
    Path:            db00
Data object read failed: File not found
Data object 'Card Holder Unique Identifier'
    applicationName: Card Holder Unique Identifier
    applicationOID:  2.16.840.1.101.3.7.2.48.0
    Path:            3000
    Data (61 bytes): 3B3019D4E739DA7...
Data object 'Unsigned Card Holder Unique Identifier'
    applicationName: Unsigned Card Holder Unique Identifier
    applicationOID:  2.16.840.1.101.3.7.2.48.2
    Path:            3010
Data object read failed: File not found
Data object 'X.509 Certificate for PIV Authentication'
    applicationName: X.509 Certificate for PIV Authentication
    applicationOID:  2.16.840.1.101.3.7.2.1.1
    Path:            0101
Data object read failed: File not found
Data object 'Cardholder Fingerprints'
    applicationName: Cardholder Fingerprints
    applicationOID:  2.16.840.1.101.3.7.2.96.16
    Path:            6010
    Auth ID:         01
Data object 'Printed Information'
    applicationName: Printed Information
    applicationOID:  2.16.840.1.101.3.7.2.48.1
    Path:            3001
    Auth ID:         01
Data object 'Cardholder Facial Image'
    applicationName: Cardholder Facial Image
    applicationOID:  2.16.840.1.101.3.7.2.96.48
    Path:            6030
    Auth ID:         01
Data object 'X.509 Certificate for Digital Signature'
    applicationName: X.509 Certificate for Digital Signature
    applicationOID:  2.16.840.1.101.3.7.2.1.0
    Path:            0100
Data object read failed: File not found
Data object 'X.509 Certificate for Key Management'
    applicationName: X.509 Certificate for Key Management
    applicationOID:  2.16.840.1.101.3.7.2.1.2
    Path:            0102
Data object read failed: File not found
Data object 'X.509 Certificate for Card Authentication'
    applicationName: X.509 Certificate for Card Authentication
    applicationOID:  2.16.840.1.101.3.7.2.5.0
    Path:            0500
Data object read failed: File not found
Data object 'Security Object'
    applicationName: Security Object
    applicationOID:  2.16.840.1.101.3.7.2.144.0
    Path:            9000
Data object read failed: File not found
Data object 'Discovery Object'
    applicationName: Discovery Object
    applicationOID:  2.16.840.1.101.3.7.2.96.80
    Path:            6050
    Data (20 bytes): 7E124F0BA0000003080000100001005F2F024000
Data object 'Cardholder Iris Image'
    applicationName: Cardholder Iris Image
    applicationOID:  2.16.840.1.101.3.7.2.16.21
    Path:            1015
Data object read failed: File not found

The lines containing Data object read failed: File not found indicate that there is currently no data loaded onto the PIV applet. Let's change that by loading a CA certificate and private key.

Importing the CA certificate and private key onto the Yubikey Neo

In order to load the p12 containing the certificate and private key onto to the Yubikey Neo we need to install the yubico-piv-tool from here

Let's install the packages we need to compile the yubico-piv-tool in case they would not yet be present on our system:

dennisverslegers@ubuntu:~$ sudo apt-get install gcc autoconf libssl-dev make pcscd libccid libpcsclite-dev

With those in place we can continue to download and compile the yubico-piv-tool:

dennisverslegers@ubuntu:~$ cd /tmp
dennisverslegers@ubuntu:/tmp$ wget http://opensource.yubico.com/yubico-piv-tool/releases/yubico-piv-tool-0.0.2.tar.gz

dennisverslegers@ubuntu:/tmp$ tar -vxzf yubico-piv-tool-0.0.2.tar.gz
dennisverslegers@ubuntu:/tmp$ cd yubico-piv-tool-0.0.2
dennisverslegers@ubuntu:/tmp/yubico-piv-tool-0.0.2$ ./configure
dennisverslegers@ubuntu:/tmp/yubico-piv-tool-0.0.2$ make
dennisverslegers@ubuntu:/tmp/yubico-piv-tool-0.0.2$ sudo make install

Now we should be able to import our p12 container containing both the certificate and private key onto the yubikey. The yubico-piv-tool indicates that the yubikey piv applet has four distinct key slots.

  -s, --slot=ENUM        What key slot to operate on  (possible values="9a",
                           "9c", "9d", "9e")

       9a is for PIV Authentication
       9c is for Digital Signature (PIN always checked)
       9d is for Key Management
       9e is for Card Authentication (PIN never checked)

In our case we only want to load the CA certificate onto the yubikey neo which will be used for digital signatures (of other certificates). Therefore we instruct the piv-tool to load the private key in slot 9c.

dennisverslegers@ubuntu:~$ yubico-piv-tool -s 9c -i Documents/project1ca.p12 -K PKCS12 -p demo -a import-key -a import-cert
Successfully imported a new private key.
Successfully imported a new certificate.

You can verify the successful import by issuing the pkcs15-tool list data objects command again.

dennisverslegers@ubuntu:~$ pkcs15-tool --list-data-objects
Using reader with a card: Yubico Yubikey NEO CCID 00 00
...
Data object 'X.509 Certificate for Digital Signature'
    applicationName: X.509 Certificate for Digital Signature
    applicationOID:  2.16.840.1.101.3.7.2.1.0
    Path:            0100
    Data (1159 bytes): 53820483
...

As you can see the Data section for X.509 Certificate for Digital Signature now indicates that data is present in this slot.With this in place we can now continue and configure openssl to use the CA certificate present on the Neo for signing of future certificate requests.

Configuring OpenSSL CA to access the CA private key located on the yubikey Neo

Before we can continue we need to determine the key ID of the CA private key on the piv applet for future use by OpenSSL.

dennisverslegers@ubuntu:~$ pkcs15-tool --list-keys
Using reader with a card: Yubico Yubikey NEO CCID 00 00
Private RSA Key [SIGN key]
    Object Flags   : [0x1], private
    Usage          : [0x20E], decrypt, sign, signRecover, nonRepudiation
    Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, local
    ModLength      : 2048
    Key ref        : 156 (0x9C)
    Native         : yes
    Auth ID        : 01
    ID             : 02
    GUID           : 024fc9a7cd8f541ecad4e39ab21a95a5

The ID of our private key located on the Neo is indicated by the ID field, in this case 02. Take a note of this somewhere for future use.

Now let's continue by installing the pkcs11 OpenSSL library:

dennisverslegers@ubuntu:~$ sudo apt-get install libengine-pkcs11-openssl

To configure OpenSSL to use the PKCS11 engine you can issue the following command from the OpenSSL prompt:

OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so
(dynamic) Dynamic engine loading support
Success: SO_PATH:/usr/lib/engines/engine_pkcs11.so
Success: ID:pkcs11
Success: LIST_ADD:1
Success: LOAD
Success: MODULE_PATH:opensc-pkcs11.so
Loaded: (pkcs11) pkcs11 engine

Note For Mac OS X the following command should be used to load the PKCS11 engine:

engine dynamic -pre SO_PATH:/Library/OpenSC/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/opensc-pkcs11.so

We can also configure OpenSSL to load the PKCS11 engine automatically at startup my modifying the openssl configuration file like so:

openssl_conf            = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
pkcs11 = pkcs11_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/engines/engine_pkcs11.so
MODULE_PATH = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
init = 0

Additionally you can add a pin entry in the pkcs11_section of the openssl configuration file to add the pin code to be used when accessing the smart card(s).

With everything in place you should be able to issue the following command to sign a certificate request using the private key located on the smartcard:

dennisverslegers@ubuntu:~/Documents/demo_pki_root$ openssl ca -engine pkcs11 -keyfile 01:02 -keyform e -config ./openssl.cnf -name Project1CA -out demo_user.crt -infiles .demo_user.csr
Using configuration from ./openssl.cnf
engine "pkcs11" set.
PKCS#11 token PIN: 
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 5 (0x5)
        Validity
            Not Before: Apr 28 13:28:30 2014 GMT
            Not After : Apr 28 13:28:30 2015 GMT
        Subject:
            countryName               = BE
            stateOrProvinceName       = Vlaams-Brabant
            localityName              = Leuven
            organizationName          = AUSY
            organizationName          = not used
            organizationalUnitName    = Demo CA project
            commonName                = demo_user
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Client, S/MIME
            Netscape Comment: 
                OpenSSL Generated Client Certificate
            X509v3 Subject Key Identifier: 
                2B:7C:DE:9E:B7:20:51:4E:60:4C:AD:F8:10:AF:97:2A:1D:6B:45:0D
            X509v3 Authority Key Identifier: 
                keyid:CE:9B:8C:9B:C8:59:66:42:49:1A:B4:F8:35:1B:9D:7F:D4:BC:90:75
                DirName:/C=BE/ST=Vlaams-Brabant/L=Leuven/O=AUSY/O=not used/OU=Demo CA project/CN=RootCA
                serial:01

Certificate is to be certified until Apr 28 13:28:30 2015 GMT (365 days)
Sign the certificate? [y/n]:

Some interesting things to know:

• default pin: 123456
• default unblock pin: 12345678
• default admin key (3des key): 010203040506070801020304050607080102030405060708

Needless to say it is recommended to say that changing the pin codes is absolutely mandatory. This can be done using the yubico-piv-tool.