Booches.nl

ISA Server 2006 array – renew certificate

When configuring a Microsoft ISA Server 2006 array you have two options for authentication and communication between the Microsoft ISA 2006 Configuration Storage Server and the array members.

• Windows Authentication: Choose this option if ISA server and the Configuration Storage server are in the same domain, or in different domains with a trust relationship between them. The connection will be encrypted (signed and sealed);
• Authentication over SSL encrypted channel: Choose this option if ISA server is in a domain that does not have a trust relationship with the Configuration Storage server domain, or if it is part of a workgroup. The connection will be SSL encrypted.

I normally configure the array members within a DMZ environment en install the CSS server on the internal network.

To maximize the security the array members aren’t part of the Active Directory. So communication between the CSS and the array members is workgroup based and the authentication type used is Authentication over SSL encrypted channel. This option needs the configuration of SSL certificates to authenticate and secure the connection. The certificates have a certain validity period, after which the certificate needs to be renewed.

Normally I always ran the repair option from the installation and specified the new certificate. I discovered a new and simpler method by using the ISACertTool. This tool provides an easy way to renew the certificate on the Configuration Storage Server and the root CA certificate on the array members.

You just need to create a web server certificate in pfx format from a Windows CA server of any other CA server. If the CA server isn’t trusted by the array members, you need to install the CA certificate on the array members. If you use trusted CA server certificate, you can skip this step.

The syntax for the ISACertTool is very straightforward. On the Configuration Storage Server you need to run the following command:

ISACertTool.exe /st <pfx file> /pswd <password> /keepcerts

On the array member you run the following command to install the root CA certificate.

ISACertTool.exe /fw <root ca file>

IMPORTANT: for a correct usage of the tool you need to extract the tool to the Microsoft ISA Server install directory, which is by default C:\Program Files\Microsoft ISA Server.

Windows LDAPS expired

A lot of appliances and/or security solutions use LDAP to synchronize users from an Active Directory or an eDirectory environment. Active Directory is LDAP enabled by default. If you would like to harden your network,  you would like to use LDAPS.

LDAPS is a term to refer to LDAP communication over SSL. Intercepted LDAPS traffic cannot be read easily by hackers. In an Active Directory environment you need to have at least one Certificate Authority (CA) to enable LDAPS. Windows uses Server Authentication certificates for the LDAPS operations.

Last week I had a customer complaining that people weren’t able to access their webmail via a Microsoft ISA reverse proxy. The cause of the problem was an expired Server Certificate on the specific domain controller. The reverse proxy server uses LDAPS to authenticate the user against an Active Directory. The following event log was found on the reverse proxy server.

To resolve the problem I had to renew the Server Authentication certificate on the domain controller. I decided to use the “Windows method” by using the Windows CA to renew the certificate. From the domain controller with the expired certificate I opened IE and enter the URL:

http://<IP address CA>/certsrv

This opens the Microsoft Certificate Services webpage of the CA. The following screenshots show the request and installation procedure for the certificate renewal.

Since I had to renew a Server Authentication certificate, I choose the option Request a certificate.

To request a Server Authentication certificate I choose the option advanced certificate request.

Normally I use OpenSSL to generate the certificate signing request, which is submitted to the CA. In that scenario I had to choose option 2. This time I decide to generate the csr via the webpage and choose the first option: Create and submit a request to this CA.

The csr is generated with the information from the screenshot above. Because I had to renew a Server Authentication certificate, I choose the Web Server certificate template. The Name field is very important and should match the FQDN of the LDAPS server. It is also important to select the Store certificate in local computer certificate store option. This ensures that the certificate isn’t installed in the user’s certificate store, because the certificate cannot be exported with private key.

When you submit the certificate request, you have to wait until the request is approved. The approval has to be done by someone who manages the CA environment. If you open the CA MMC snap-in you will see one or more pending request. The pending request needs to be approved. After the request was approved, I browsed to the Microsoft Certificate Services webpage, like shown below.

I choose the option View the status of a pending certificate request. Remember that I did the whole procedure on the LDAPS server to be sure that the certificate is stored in the servers local computer certificate store. The last step involves installing the certificate in the local computers certificate store. After the installation I always check the store to see if the private key is present for the certificate.

The renewal of the certificate is almost done. The LDAPS services depends on the process LSASS.exe. To “associate” the SSL certificate with the LDAPS server I needed to reboot the server. During the reboot the first valid Server Authentication SSL certificate within the local computer certificate store is used by the LDAPS server.

The reverse proxy server was able to use LDAPS again after the reboot of the specific domain controller.

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.