Creating a web server certificate request is very easy when using a Windows CA server. There is one disadvantage. The requested certificate is directly stored in the user store (by default) or the local computer store, if specified during the request. The disadvantage is that you cannot export the requested certificate including the private keys. During the request the option to Mark keys as exportable is grayed out.
There is a way to mark the keys as exportable when using a Windows CA server. You need to create a new Web Server Certificate template. You can use the existing Web Server Certificate Template as default and copy the current settings. To do so, you just:
That is all you need to do. You can now request a new certificate with the newly create certificate template. After the certificate is issued and installed on the user or local computer store, you can export the certificate including the private key.
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:
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
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
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:
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.
I found this procedure in the Microsoft Knowledge Base and used it on Microsoft Windows 2003 and Microsoft Windows 2008.
Today I received the question about allowing users to changes his/her password through webmail, whereby webmail is published via an ISA server 2006 reverse proxy. This is possible, but it requires the configuration of LDAPS to authenticate users.
I started by configuring a Certificate Authority (CA) on a member server in the domain. During the installation of CA a root certificate is generated. You need to export this root certificate with private key. Next I imported the certificate on the reverse proxy server, but didn’t mark the private key as exportable. So the root certificate cannot be exported from the reverse proxy server with its private key in the future. I checked if binding to the Active Directory is possible by using the tool ldp.exe.
The last part is configuring LDAP Validation in ISA. Go to Configuration –> General –> Specify RADIUS and LDAP Servers. First you need to add a LDAP server set, like shown in the following picture.
Important when configuring the LDAP server set is the usage of the FQDN as LDAP server hostname. This FQDN should be exactly the same compared to the FQDN mentioned in the imported root certificate.
The last step is configuring the LDAP server mapping, which is also shown below.
Because I don’t want to add a domain name during the login procedure on the OWA login page, like DOMAIN\USER, I use the Login Expression wildcard character * and link that to the configured LDAP server set. Now you can login with just username and password, instead of domain\username and password.
Next I configure a OWA Publishing policy like always, but on the Listener I use LDAP as authentication mechanism. On the Listener Forms tab you can enable or disable the options:
These options add some extra option to the OWA login page. Another step to configure is the allowed users. In most environments I use the group Domain Users as allowed OWA group, because mostly all users are allowed to use OWA, else you need to configure a separate user group in Active Directory. On the Users tab you remove the All Authenticated Users and click Add. You need to define a new user group, like shown below.
This means that if you are member of the group Domain Users, you are allowed to use OWA.
The last step is configuring the public path. When logged in to OWA, you have the option to change your password through the options page. To use this feature, you need to added another path to the Path configuration in the reverse proxy server. The path, which should be added, is /iisadmpwd/*, where the External Path is the same as the Internal Path.
Over at isaserver.org, Thomas Shinder wrote a great post about using LDAPS with OWA and multiple domains. The article is called LDAP Pre-Authentication with ISA 2006 Firewalls: Using LDAP to Pre-Authenticate OWA Access.