Archive

Archive for May, 2013

What is a SSL certificate chain ?

May 26th, 2013 1 comment

When you buy a SSL certificate from Certificate Authority (CA) (In this topic I will use Entrust as the CA), Entrust does not issue you a single cert. They issue you a SSL Chained cert. When you download and open the zip file from Entrust, you will see the following certificate bundle:

Let’s analyze these certs in your chain. The first one is L1Croot.txt which is called the “root certificate”. This is the first cert in your chain. This root cert is installed to the Trusted Root Certification Authorities store on your server or network appliance.

The second cert in your chain is L1Cchain.txt which is “intermediate certificates”. An intermediate cert is essentially a certificate issued by the Trusted Root CA specifically designed to issue SSL Certificates to you. The reason for this is because if the CA root cert were to ever be compromised, the entire chain fails. It is good security practice to use an “intermediary” to issue the certs from to prevent your root CAs from being exposed from the signing process. If an intermediate were to ever be compromised, you can always regenerate those unlike the root certs. This intermediate certificate sits between your website cert and the root cert. This intermediate cert is installed to the Intermediate Certification Authorities store on your server or appliance.

The last cert in your chain is entrustceert.crt which is your actual SSL cert. This is also known as your “domain certificate”. This domain cert is installed to the Personal store on your server or appliance.

So the end result is chain of certs that begins at the trusted root CA, runs through the intermediary, and finally ends with the SSL certificate issued to you for your website or appliance (domain.com).

In most cases, any sever or appliance out there will already have the trusted root cert for Entrust installed. You can just install your SSL cert and not have to worry about anything else in most cases. Depending on where you buy your cert from and what you are trying to install your cert to, you may have to go through the steps of installing the Trusted Root cert and Intermediate cert first before installing your SSL cert. With some web browsers like Internet Explorer 7 for example, you can get away with not having to install any Intermediate Certificate because IE7 will automatically go out automatically download the intermediate cert the first time a user visits your website. This makes things easy for the lazy admin but it’s always best practice to go a head and add the Intermediate cert on your end instead of depending on the client and their browser’s ability to do this. There is no point in risking a certificate error for the end user when the fix is so easy.

To verify the chain, go to any site you know that uses SSL (https://) and then click on the lock in Internet Explorer, it will let you view the SSL cert info. Click the “Certificate Path” tab and you can see the chain we described above:

Trusted Root —> Intermediate —> SSL Certificate
sslchained
You can then click on each one of these certs and hit the “View Cert” button to view each cert in the chain individually. Good luck and post a comment if you have any questions.

Categories: SSL Certificates

What happens when the vCenter crash?

May 22nd, 2013 Comments off

Seva, a VMware Technical Account Manager, put together a cool table with the implications of a VirtualCenter crash. Click the image for the pdf file. The most important thing to remember is that the VM’s keep running whatever happens to your VC Server and HA will still work if VC fails.
vc-crashes

Categories: Virtualization

Use old routers for WAN simulation

May 18th, 2013 2 comments

When I was playing with Citrix today, I needed to slow down my 1Gbs connection. My first thought was to use a WAN simulator, but the cost for one, even the entry model is over $3000 . Luckily I have a few old Cisco Routers that I can use. There is a feature called Committed Access Rate (CAR) that you can se to limit the traffic on an interace. Let limit ICMP traffic on interface 0 to 8kps , 2KB for normal and 4KB for excess burst values

Let’s test it

Categories: Networking

Map certificates to Tunnel Groups on Cisco ASA FWs

May 9th, 2013 Comments off

Yesterday I noticed some strange messages in my syslog

Turned out that on ASA Firewalls that have more than 1 Connection Profiles that use certificate authentication, you will need to map the certificates to the Tunnel Groups

Mapping the certificates to specific tunnel-groups can be done in the CLI or in the ASDM. Since the trend or push now by Cisco is mostly using the ASDM, you might as well get used to it. In all honesty, it’s extremely functional and once you get used to it very easy to navigate.

Capture1

Then pick a name for the rule and select the Connection Profile

Capture2

For security reasons, I would always set anything that has to do with the Default tunnels, policies, maps, etc. to disconnect in a separate DAP policy. That way if a connection attempt is made that you have not explicitly defined or allowed, it will be terminated. For this reason we will chose the “New” button and name our map something intuitive that will allow us to immediately associate it to the tunnel we are mapping it to! For instance if your tunnel is called “marketing_tunnel” and your policy for that tunnel is “marketing_policy” – name your map “marketing_certmap”. Trust me; this makes life much easier on a busy ASA when you are troubleshooting. Also create your certificate maps in the order of importance that will make the “Priority” relative by default. Chose the connection profile (tunnel-group) you wish to map this rule to and click “Ok”.

Next we need to define the criteria (certificate values) that will be used for the certificate map. As of 8.4, there are four sections to the criterion: Field, Component, Operator, and Value.

Capture3

In the above example we are using criteria that would specify the name and domain of the person or device trying to authenticate. For this device it would be something like testserver.mycompany.com or testserver@mycompany.com. All of this information must be present on the certificate it was issued or it won’t be passed to the ASA during the authentication process.

In the example above, we are specifying that the certificate issuer is being used to map the connection to a specific tunnel group. You may have more than one CA in your organization, each one used for different purposes. For Example: A CA that is used for laptops authenticating to the wireless infrastructure, A CA that is used for the users to authenticate to the VPN, and a CA that is used for your mobile devices to authenticate wireless and VPN. In all of these circumstances, because the CN for each CA will be different – you can assign each type of device to a different tunnel-group, and apply different policies or restrictions to those tunnel groups.

Categories: Networking, Security
l>