Monthly Archives: April 2014

Routing / switching, Security, Wireless

Cisco Prime Infrastructure import certificates made easy

Working with certificates time to time can be a little difficult, implementations differ and there are more than one certificate “formats”. This is also the case when it comes to importing a “pfx” archive to Cisco Prime Infrastructure (1.x or 2.x). If you search the web you will find a lot topics, but you will have to mix those together to get the job really done.

In this scenario you have a wildcard certificate and the private key combined together in a pfx archive (cert.pfx). You will need a openssl installation, the CA bundle (Root certificate and intermediates certificates, “CA-CERTS.CER”) which you can download from the certificate authorities website and these six steps:

1. Export the pfx archive to a standalone certificate and private key
openssl pkcs12 -in cert.pfx -nocerts -out key.pem
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem
2. Decrypt the private key
openssl rsa -in key.pem -out key2.pem
3. Convert certificate from pem to der format
openssl x509 -outform der -in cert.pem -out cert.der
4. Download the “CA-CERTS.CER”, “key2.pem” and “cert.der” files with FTP from the Prime CLI
5. Import the CA certs in Prime:
PRIME/admin# ncs key importcacert CA-CERTS CA-CERTS.cer repository defaultRepo
INFO: no staging url defined, using local space. rval:2
truststore used is /opt/CSCOlumos/conf/truststore
The NCS server is running
Changes will take affect on the next server restart
Importing certificate to trust store
6. Import certificate and private key
PRIME/admin# ncs key importkey key2.pem cert.der repository defaultRepo
INFO: no staging url defined, using local space. rval:2
INFO: no staging url defined, using local space. rval:2
truststore used is /opt/CSCOlumos/conf/truststore
The NCS server is running
Changes will take affect on the next server restart
Importing RSA key and matching certificate
7. Restart the NCS application, and drink a cup of coffee.. 😉
PRIME/admin# ncs stop
PRIME/admin# ncs start

Routing / switching, Security

Cisco AnyConnect VPN connected through a firewall

Most Cisco AnyConnect VPN configurations I see in the field, or have deployment myself, are terminated on a Cisco ASA firewall who is directly connected to the internet. However, in some bigger networks it is not uncommon to have another firewall in front of the remote access / VPN block in your network or to have an access-list on the routers in the internet edge.

Everybody knows the story about the biggest pro which the Cisco AnyConnect solution has if you compare it to the old IPSEC remote access based solution –> “it just works everywhere™”. That story is based on the fact that in most guest and mobile networks SSL network traffic (TCP/443) is allowed. This is true; AnyConnect will work fine if DNS is working and TCP port 443 is open. However, AnyConnect will try to use the DTLS protocol first which uses UDP port 443, if it fails than the client will fall back to use SSL for the transport of user data. The reason that AnyConnect prefers DTLS is that DTLS has less delay because of the connectionless nature of UDP and thus performance is better then with a SSL tunnel.

It is very easy to check if you are actually using DTLS in the AnyConnect client:

Cisco AnyConnect DTLSConclusion:
 If you filter the network traffic destinate to a Cisco IOS webvpn router or Cisco ASA firewall in the remote access / VPN block in your network don’t forget to open UDP port 443 also.. 🙂