Booches.nl

Import PKCS12 certificate on IOS router

Nowadays IOS routers can be configured with WebVPN (Clientless SSL VPN) functionalities. WebVPN allows a user to securely access resources on the corporate LAN from anywhere with an SSL-enabled Web browser. To secure the connection you should use a SSL certificate to encrypt all transferred data. There are different ways of creating and importing SSL certificates on an IOS router, but I always use the same method:

1. 1. I generate a CSR and private key on my own laptop with Cygwin and OpenSSL;
2. 2. I sent the CSR to a CA for signing, like VeriSign or GeoTrust;
3. 3. I create a PKCS12 certificate with the signed cert and the private key;
4. 4. Import the PKCS12 certificate on the router;

With this procedure I always have the “real” certificate, and all related files, on my own laptop for backup purposes. Mostly you can also generate a CSR on an appliance and import the signed certificate to the appliance and you are also done. But sometimes you don’t have the opportunity to export the certificate for backup purposes. So what if the appliance crashes or needs to be replaced?

Now I will show you how to import the PKCS12 to an IOS router. First we need to create a trustpoint on the router. The trustpoint contains the certificate authority that signed the certificate in use.

router(config)#crypto pki trustpoint trustpoint_www
router(ca-trustpoint)#fqdn www.booches.nl
router(ca-trustpoint)#subject-name cn=www.booches.nl
router(ca-trustpoint)#revocation-check crl
router(ca-trustpoint)#rsakeypair trustpoint_www

Next I will import the certificate. There are multiple ways for importing the certificate, but I just use TFTP to transfer the certificate from my laptop to the router.

router(config)#crypto ca import trustpoint_www pkcs12 tftp: passphrase
% Importing pkcs12…
Address or name of remote host []? 10.10.1.58
Source filename [trustpoint_home]? www-booches-nl.pfx
Reading file from tftp://10.10.1.58/www-booches-nl.pfx
Loading www-booches-nl.pfx from 10.10.1.58 (via BVI1): !
[OK - 2629 bytes]

CRYPTO_PKI: Imported PKCS12 file successfully.

The certificate is now successfully imported into the router and can be associated with the WebVPN configuration. Useful commands to verify your trustpoints and certificates are:

show crypto pki certificates
show crypto pki trustpoints

OpenSSL & Cygwin – Certificate Authority

I am using OpenSSL in conjunction with Cygwin on my Windows laptop to generate Certificate Signing Request and other SSL certificate related issues. Today I configured my own Certificate Authority, using the following guideline.

Preparations

First I created some directories, like shown below:

mkdir /home/sslCA
cd /home/sslCA
mkdir certs private newcerts

Next I created a serial file which will be used to name the new certificates generated and an index.txt file.

echo 1000 > serial
touch index.txt

Generating the CA

After setting up the appropriate directory, I generated the Certificate Authority, like shown below.

cd /home/sslCA
openssl.exe req –new –x509 –days 3650 –extensions v3_ca \
-keyout private/cakey.pem –out cacert.pem \
-config /usr/ssl/openssl.cnf

The command above generates the following output:

Generating a 1024 bit RSA private key
.++++++
…………………++++++
writing new private key to ‘private/cakey.pem’
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) [NL]:
State or Province Name (full name) [Some-State]:Noord-Brabant
Locality Name (eg, city) []:Eindhoven
Organization Name (eg, company) [Internet Widgits Pty Ltd]:4IP BV
Organizational Unit Name (eg, section) []:IP Consultancy
Common Name (eg, YOUR name) []:4IP Root CA
Email Address []:

Now I have a running Certificate Authority, which is ready to signing new certificates.

Performing an SSL Request

I used the following command, with it’s output, to generate an SSL Certificate Signing Request.

cd /home/sslCA
openssl req –new –nodes \
-out cert-www-4ip-nl.pem \
-keyout private/priv-www-4ip-nl.pem \
-config /usr/ssl/openssl.cnf

Generating a 1024 bit RSA private key
………..++++++
….++++++
writing new private key to ‘private/priv-www-4ip-nl.pem’
—–
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) [NL]:NL
State or Province Name (full name) [Some-State]:Noord-Brabant
Locality Name (eg, city) []:Eindhoven
Organization Name (eg, company) [Internet Widgits Pty Ltd]:4IP BV
Organizational Unit Name (eg, section) []:IP Consultancy
Common Name (eg, YOUR name) []:www.4ip.nl
Email Address []:

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Signing CSR

The last step in the process is signing the CSR. I used the following command to sign the CSR.

openssl ca –config /usr/ssl/openssl.cnf \
-out sslcert-www-4ip-nl.pem \
-infiles cert-www-4ip-nl.pem

This command results in the following output:

Using configuration from /usr/ssl/openssl.cnf
Enter pass phrase for /home/sslCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4096 (0×1000)
        Validity
            Not Before: Sep 30 11:01:11 2009 GMT
            Not After : Sep 28 11:01:11 2019 GMT
        Subject:
            countryName               = NL
            stateOrProvinceName       = Noord-Brabant
            organizationName          = 4IP BV
            organizationalUnitName    = IP Consultancy
            commonName                = www.4ip.nl
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                37:6B:52:95:B6:2D:26:76:C1:CD:E9:3C:58:E5:89:B4:26:34:83:43
            X509v3 Authority Key Identifier:
                keyid:64:6A:E7:65:B0:96:F6:56:49:A2:4D:EA:7F:68:3F:18:D1:86:2B:0E

Certificate is to be certified until Sep 28 11:01:11 2019 GMT (3650 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Now I have all the appropriate files:

• Certificate: /home/sslCA/sslcert-www-4ip-nl.pem
• Key: /home/sslCA/private/priv-www-4ip-nl.pem

Converting to PKCS#12

Windows environments normally use PKCS#12 files. The following command generates a PKCS#12 file with the user certificate, the private key and the CA certificate:

cd /home/sslCA

openssl pkcs12 –export –out www-4ip-nl.pfx \
-inkey private/priv-www-4ip-nl.pem \
-in sslcert-www-4ip-nl.pem \
-certfile cacert.pem

This commands generates the appropriate PFX file (www-4ip-nl.pfx) for specific Windows environments, like IIS. Other usefull commands to convert certificate formats can be found here.

Microsoft CA certificate validity period

Using a Microsoft CA is very common in network to issue self-signed certificates. Last week I had to configure a Windows IIS server with client certificate authorization. Remote people (non Active Directory users) need a client certificate to browse to a specific website. The communication between the remote user and the website is secure by a default SSL web certificate.

The website is configured to require SSL and client certificate authentication. Within IIS I configured Client Certificate Mappings to authenticate the remote users. To create Client Certificate Mappings I had to generate client certificates. Client certificates can be generated by installing a Microsoft Certificate Authority. You can also use OpenSSL to generate client certificate, but this customers has a complete Microsoft Windows environment, so I decided to install a Microsoft CA.

You can install two kinds of CA’s:

• Stand-alone CA
• Enterprise CA

A standalone CA does not issue certificates independent of administrator intervention. The reasoning for this is based upon the fact that a standalone CA doesn’t tap into a local or domain user account. Instead, it relies upon human intervention as a ‘last check’ method prior to issuing a certificate. Standalone CA certificates are also not distributed automatically, but further require a delivery method, such as group policy (for local domain users), or via further human intervention. For Web and Internet access, this is the type of CA to use.

The enterprise CA adds a new level of flexibility and ability to the certificate picture, but also added complexity. The Enterprise CA is integrated with Active Directory, and only provides certificates to members within that Active Directory. This pretty much kills the idea of having both an extranet or secure Internet communications along with secure local domain communications. Enterprise Certificates can, however, be used in a manner that falls within the ‘not often, but still really nifty’ category. Enterprise Certificates can be used to bypass repeated and redundant domain authentication, and when properly configured, can be used to further enhance the standard Kerberos authentication methods. Enterprise Certificates are automatically issued for every user account when it is created. The certificate itself, since it is a file, can be stored on any storage location and can still be valid. In keeping along this train of thought, it is possible to place a certificate on a card or plug-in device that can be used to authenticate a user during the normal Kerberos authentication process. These specialized devices are called Smart Cards, and while Smart Card implementation is somewhat expensive, several large corporations have implemented this technology as an added safety factor. […] Source

I decided to install a Standalone CA server, so client certificates can be generated with credentials from the remote users. When using an Enterprise CA, the client certificate contains the credentials from the Windows users who generates the request. The Enterprise CA requires Windows Integrated Authentication to perform a request.

Everything is working perfectly, the only caveat was the validity period of the client certificates. By default, the lifetime of a certificate that is issued by a Stand-alone Certificate Authority CA is one year. The validity period that is defined in the registry affects all certificates that are issued by Stand-alone and Enterprise CAs. For Enterprise CAs, the default registry setting is two years. I used the following procedure to change the default validity period from one year to two years.

1. Click Start, and then click Run
2. In the Open box, type regedit, and then click OK
3. Locate, and then click the following registry key:
   • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>
4. In the right pane, double-click ValidityPeriod
5. In the Value data box, type one of the following, and click OK
   • Days
   • Weeks
   • Months
   • Years
6. In the right pane, double-click ValidityPeriodUnits
7. In the Value data box, type the numeric value that you want, and then click OK. In my situation I used the value 2
8. Stop and then restart the Certificate Services service. To do so
   • Click Start, and then click Run
   • In the Open box, type cmd, and then click OK
   • At the command prompt, type the following lines.
   • net stop certsvc
   • net start certsvc
9. Type exit to quit Command prompt.

I found this procedure in the Microsoft Knowledge Base and used it on Microsoft Windows 2003 and Microsoft Windows 2008.

Cygwin with OpenSSL for CSR generation

A lot of services, which are published to the Internet, are secured with SSL certificates. A lot of times we use SSL certificates to secure communications when implementing ISA reverse proxy servers, Citrix Secure Gateway servers and/or Cisco WebVPN portals.

When you want to secure a connection with a SSL certificate you have to create a Certificate Signing Request (CSR) and get the CSR signed by a Certificate Authority (CA). This can be done by a “real” CA, like GeoTrust or Verisign, or you can configure your own CA and sign your own CSR.

There are a lot of ways for generating CSR’s. In first I always used what the customers could offer me. This could be the Cisco ASA firewall, a Windows server with IIS or the Juniper SA appliance. Sometimes could take a couple of hours before I could finally generate a CSR. While generating a CSR, a private key is also generated. When using customer equipment for generating the CSR, it could happen that the customer deletes the private key, which makes the CSR useless.

A colleague of mine often has the same problems and he started using Cygwin with OpenSSL under Windows. I have to say, GREAT. I started using it myself. A great advantage is that I can use my own laptop and I don’t have to depend on the customers equipments. Furthermore, and maybe the most important, I know what I am doing during the generation and signing of certificates, so I will never delete the wrong files.

Normally I generate a new private key per certificate and I use the following commands for generating the private key, CSR and the actual certificate.

1. Generate a private key

openssl.exe genrsa -out private-www-booches-nl.key 1024

2. Generate the CSR, fill in the required information (common name is the most important)

openssl.exe req -new -key private-www-booches-nl.key -out csr-www-booches-nl.csr

3. The CSR is uploaded to the CA. The CA sends you the SSL certificate, which I save as www-booches-nl.crt

4. Create the actual SSL certificate

openssl.exe pkcs12 -export -out www-booches-nl.pfx -inkey private-www-booches-nl.key -in www-booches-nl.crt

When using an Open Source web server you have to use a certificate with a DER format. The first 3 steps, as shown above, are still the same. You can use the following steps to create a DER file.

4. Put the key file code at the end of the crt file

cat private-www-booches-nl.key >> www-booches-nl.crt

5. Create the DER file

openssl.exe x509 -in www-booches-nl.crt -inform PEM -out www-booches-nl.der -outform DER

It is also possible that you need a PEM certificate instead of a PFX certificate. Below you see the command to create a PEM certificate from a PFX certificate.

6. Create the PEM file

openssl.exe pkcs12 -in www-booches-nl.pfx -out www-booches-nl.pem -nodes

Using Cygwin with OpenSSL really makes it easier when working with CSR’s and certificates. A very usefull website with “The Most Common OpenSSL Commands” can be found here.

PDA Active Sync – Invalid Certificate

The usage of Pocket PCs (PDAs) becomes more and more a default feature for business. The last months I have installed quit some Windows ISA 2006 servers for Reverse Proxy purposes. I have installed them normally for webmail only, but lately I have added the Microsoft Active Sync feature.

The Pocket PCs connect to the organization via UMTS, GPRS, USB with laptop or whatever with an internet connection. Today I had the same job on the schedule: Enable Active Sync for Pocket PCs.

I thought by myself: EASY JOB, but NOT. After configuring the ISA reverse proxy I used a Pocket PC emulator to test the Active Sync features. I received the following error message when synchronizing:

I found this a strange message, because clients use the same URL as the Pocket PC for accessing their webmail and they never receive an error message for an untrusted certificate.

The used certificated is issued by Equifax Secure Global eBusiness CA-1. This is a common and one of the better CA’s.

I had to dig deeper into the problem. I tried to install the certificate on the Pocket PC, but no luck. I searched the internet and found a tool called Microsoft Exchange Server Disable Certificate Verification. You can find an executable here, which can be used when using the Pocket PC in conjunction with a PC through USB. I also found a similar tool to install on the pocket PC, this is called AS_Cert_OFF.cab. The tool wasn’t the solution to the problem, so I had to dig deeper.

I was thinking way to complex, the problem was fixed by requesting a new certificate. The used certificate didn’t support Pocket PC. Comparing the different SSL certificates on QuickSSL.com I noticed I had to use a QuickSSL Premium certificate. This certificate supports popular mobile devices and smartphones.

After generating a CSR, requesting the certificate and installing the certificate on the ISA server, the connection and synchronization works like a charm. At least for the most PDA’s. Some PDA’s received the following error 80072f7d. After searching some forums, I found the solution in adding a registry key. I added the following registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows CE Services]
“AllowLSP”=dword:00000000

After adding the key to the registry, all Pocket PC’s synchronized perfectly.