OpenSSL CA cannot sign request?!

Got the following error after signing one ore more requests?

failed to update database
TXT_DB error number 2

This is due to you are signing a request having duplicated CN.  That is, another request you signed before was having the same CN as the one you sign this time.

To allow signing duplicated CN, you need to edit the index.txt.attr file in your CA.  Change

unique_subject = yes

to

unique_subject = no

You will not encounter the same error again.

Creating a CA on Ubuntu

A more formal setup for a CA this time compared to the previous "Quick and Dirty" notes.

First of all, install a fresh Ubuntu.  I choose 12.04 LTS Server because of longer term support.

After installation, run the update commands to patch the systems:
$ sudo apt-get updates
$ sudo apt-get dist-upgrade

Reboot the system, as the previous command also upgrade the kernel.

Let's edit the defaults for OpenSSL in Ubuntu.  Configuration file is located at /etc/ssl/openssl.cnf. 

Look for the following:

[ CA_default ]
dir = ./demoCA

Change it to:

[ CA_default ]
dir = /opt/WhiteHat-CA

Also look for

policy = policy_match

Change it to:

policy = policy_anything

You can also make changes to [ req_distinguished_name ] for different default values.

This time, as we create a static CA.  Let's put it in /opt/WhiteHat-CA (or any name you like under /opt that you specified in the configuration file above).

$ sudo mkdir /opt/WhiteHat-CA

We then secure it, making only root (sudoers) can access the CA.

$ sudo chmod 700 /opt/WhiteHat-CA

Create the nessessary folders in the CA:

$ sudo mkdir /opt/WhiteHat-CA/certs
$ sudo mkdir /opt/WhiteHat-CA/private
$ sudo mkdir /opt/WhiteHat-CA/newcerts

Create the serial number file

$ sudo echo 1000 > /opt/WhiteHat-CA/serial

And create the index.txt file

$ sudo touch /opt/WhiteHat-CA/index.txt

Lastly, we create the private key and the cert for the CA:

$ sudo openssl req -new -x509 -days 3652 \
-extensions v3_ca \
-keyout /opt/WhiteHat-CA/private/cakey.pem \
-out /opt/WhiteHat-CA/cacert.pem

That's it!

Since we secured the CA, if you need to operate the CA (execute openssl ca commands), you need to sudo in order to get have required permission.

Unofficial: Replacing HP ArcSight Logger private key and certificate for web management console

From management  console, it does not allow you to import a private key.  Sometimes if it is mandatory to pre-generate the key from another sources, you will not able to use the pre-generate key.

However, replacing the private key and certificate is not that difficult.  They are located at

/opt/arcsight/logger/userdata/platform/ssl.crt

assuming the installation folder is /opt/arcsight/logger.

The private key file, must be not encrypted (-nodes), is called server.crt.  The certificate file is called server.pem.

Replacing these two files with your own pre-generate private key and certificate, then restart the HP ArcSight Logger service.  This makes the newly loaded private key and certificate effective.

This is not officially supported by HP, I think.

Quick and Dirty Steps: Create a CA, Generate a CSR and Sign the CSR with OpenSSL (on Ubuntu)

It is actually fairly easy.  Default openssl options (on Ubuntu) points the CA to ./demoCA (a folder called "demoCA" in the currrent folder).

Create a CA:
mkdir demoCA
cd demoCA
mkdir certs private newcerts
echo 1000 > serial
touch index.txt
openssl req -new -x509 -days 3652 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem
cd ..

Generate a CSR - on the folder containing "demoCA" folder:
openssl req -out A.csr -new -newkey rsa:2048 -keyout A.key

Sign the CSR with the CA - on the folder containing "demoCA" folder and A.csr:
openssl ca -out A.pem -infiles A.csr

Some time your device may only accept PKCS#12 format.  Once you have the key and the cert, you can convert it to PKCS#12:
openssl pkcs12 -export -in A.pem -inkey A.key -out A.p12 -name "A"

In order for your device to trust the cert (A.pem or A.p12), you will need to import the CA cert (./demoCA/cacert.pem).

iOS native IPSec VPN with a FortiGate using certificates and AD (LDAP) authentication

Is the title too complicated?  Let me explain a bit about the requirements:

1. iOS native IPSec VPN - that is make VPN between an iOS device and a FortiGate without additional software install on the iOS device
2. User credential checked against Active Directory (over LDAPS)
3. Certificate based VPN (do not allow to use preshare key and allow on demand VPN with iOS device)

All in one shot!  This example uses FortiOS 4.0 MR3 Patch 15 (FOS 4.3.15).

You need a working Microsoft Active Directory Domain with Enterprise CA enabled.  Without this, you cannot really do LDAPS and hance authtication information will be travel in plain text from FortiGate to MSADDC.  I use Windows 2008R2.  IP address of your DC in this example is 192.168.1.1

Once the DC and CA (actually can be on the same computer for lab exercise demo) ready, you need to create a user group, say "VPN" in Active Directory Users and Computers.  At your domain controller, open a command prompt and enter the following:

dsquery group -name "VPN"

You should have a result looks like:

"CN=VPN,OU=Builtin,DC=domain,DC=com"

You will need this information in setting up the user group in FortGate in later stage.

First, you need to have your CA cert exported - you only need the CA cert, no need to export the key.  Then in FortiGate, create the CA cert entry:

config vpn certificate ca
    edit "EXAMPLE_CA"
        set ca "-----BEGIN CERTIFICATE-----

CONTENTS REMOVED DUE TO SECURITY - YOU SHOULD HAVE THE CERT HERE

-----END CERTIFICATE-----"
    next
end

In FortiGate, create a LDAPS entry.

config user ldap
    edit "EXAMPLE-DC"
        set server "192.168.1.1"
        set cnid "sAMAccountName"
        set dn "OU=Users,DC=example,DC=com"
        set port 636
        set type regular
        set username "example\\domainuser"
        set password ENC ENCRYPTEDPASSWORDGOESHERE
        set secure ldaps
        set ca-cert "EXAMPLE_CA"
    next

Then create the user group.  The group-name here is the result comes from the command prompt output in the DC.

config user group
    edit "LDAP-VPN"
        set member "EXAMPLE-DC"
            config match
                edit 1
                    set server-name "EXAMPLE-DC"
                    set group-name "CN=VPN,OU=Builtin,DC=domain,DC=com"
                next
            end
    next
end
Load a VPN cert.  REMEMBER THE COMMON NAME OF THIS CERT MUST MARCH THE CONNECTING HOSTNAME.  So if your iOS devices connects to vpn.example.com, then the common name of this cert must be the same.

config vpn certificate caedit "ipad"
        set password ENC ENCRYPTEDPASSWORDGOESHERE
        set private-key "-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,4BD4C7C7AC6240E3

CONTENTS REMOVED DUE TO SECURITY - YOU SHOULD HAVE THE KEY HERE

-----END RSA PRIVATE KEY-----"
        set certificate "-----BEGIN CERTIFICATE-----

CONTENTS REMOVED DUE TO SECURITY - YOU SHOULD HAVE THE CERT HERE

-----END CERTIFICATE-----"
    next
end

Create interface base Phase 1.  Assuming the WAN interface is called "wan"

config vpn ipsec phase1-interface
    edit "IPSEC_iOS"
        set type dynamic
        set interface "wan"
        set dhgrp 2
        set authmethod rsa-signature
        set xauthtype auto
        set mode-cfg enable
        set proposal 3des-md5 3des-sha1
        set rsa-certificate "ipad"
        set authusrgrp "LDAP-VPN"
        set ipv4-start-ip 192.168.2.1
        set ipv4-end-ip 192.168.2.254
        set ipv4-netmask 255.255.255.0
        set dns-mode auto
        set banner "Welcome to EXAMPLE VPN!"
    next
end

Create interface based Phase 2:

config vpn ipsec phase2-interface
    edit "IPSEC_iOS"
        set keepalive enable
        set phase1name "IPSEC_iOS"
        set proposal aes256-md5 aes256-sha1
        set dhgrp 2
    next
end

Make a static route for this newly created range.  "0" here means to create a new entry.

config router static
    edit 0
        set device "IPSEC_iOS"
        set dst 192.168.2.0 255.255.255.0
    next
end

It would be nice to define this range in an address object.

config firewall address
    edit "IPSEC_iOS_RANGE"
        set associated-interface "IPSEC_iOS"
        set subnet 192.168.2.0 255.255.255.0
    next
end 

Create the firewall policy.  Again "0" here means create a new entry.

config firewall policy
    edit 0
        set srcintf "IPSEC_iOS"
        set dstintf "Internal"
            set srcaddr "IPSEC_iOS_RANGE"            
            set dstaddr "all"            
        set action accept
        set schedule "always"
            set service "ANY"            
        set logtraffic enable
        set nat enable
    next
end
That's it for the FortiGate configuration.

Now come to configure the iOS device.  First you email (or better deploy via MDM) the P12 certificate to the iOS device.  Then create the VPN entry as follow:

 

And you can enable the VPN, a welcome message will show up.

 

 

Notice the "VPN" logo on the upper left conner.  Enlarged for reference:

 

 

FortiGate Cookbook shall include this. 

 

Enjoy!

Using DDNS on ScreenOS Device

By default, DDNS (using DynDNS.org) does not work on ScreenOS device.

With everything correctly set, the system log still shows it does not work: PKI: Cannot build certificate chain for cert with subject name CN=members.dyndns.org,OU=Domain Control Validated - QuickSSL Premium(R),OU=See www.geotrust.com/resources/cps (c)10,OU=80401367,O.

The root certificate of members.dyndns.org (Equifax Secure Certificate Authority) is not installed on the ScreenOS device.  It is required to be installed manually.  Download the Equifax Secure CA root certificate to your local computer, then import it to your ScreenOS device.

After importing the CA cert, the DDNS works: Success response received for DDNS entry update for id 1 user "someuser" domain "someuser.homeip.net" server type "DYN" name "members.dyndns.org".

Experience with Hongkong Post e-Cert

In sort, frustrated.

(1) I waited 45 minutes at the designated post office. The staff members there are not so familiar with the system. Moreover, the system halt up and need a reboot. The reboot took 20 minutes. One of the staff members told me that the e-Cert system had not been updated for 10 years.

 

 

(2) They mail the smartcard to me, but for a wrong postal address. This is not the first time I apply for Hongkong Post e-Cert. I had put the postal address as my office address this time. However, they actually mailed to my home address.

 

 

(3) The smartcard I received is not windows CSP compatible. When I put it into a PC/SC compatible reader, Windows 7 prompt to install drivers. However, the card result in driver not found. The software come with Hongkong Post (downloadable online) actually extract the p12 (PKCS#12) file from the card and save it on to the file system - without the need for the a password/passphase. This means, the card is a memory card. If this is the case, no need to use smartcard as a delivery medium. The principle of using a smardcard is to make sure the private key is not able to be duplicated.

 

 

(4) The current CPS stated e-Cert for a person (personal/organizational/encipherment) cannot generate user's own key-pair. The key-pair is generated by Hongkong Post on behalf of the user. This post a risk of key leakage, as mentioned on (3), anyone with the p12 file can brute force the password/passphase. And Hongkong Post use 16-digit numeric only passphase. This make the possibility of getting the private key much easier.

 

 

After all, the risks and concerns are quite high in the overall e-Cert provisioning process. I think this should be reported to OGCIO, and the audit body of Hongkong Post e-Cert CA.