Cisco NAC Appliance - Clean Access Server Installation and Configuration Guide, Release 4.1(2)
Administering CAS Certificates, Time, Support Logs
Downloads: This chapterpdf (PDF - 1.75MB) The complete bookPDF (PDF - 11.87MB) | Feedback

Administering CAS Certificates, Time, Support Logs

Table Of Contents

Administering CAS Certificates, Time, Support Logs

Status Tab

Clean Access Server Direct Access Web Console

Manage CAS SSL Certificates

SSL Certificate Overview

Web Console Pages for SSL Certificate Management

CA-Signed Certificates

Intermediary Certificates

Non-Standard Certificates

Certificates for High Availability (HA) Pairs

Regenerating Certificates for DNS Name Instead of IP

Typical CAS Certificate Steps for New Installs

Generate Temporary Certificate

Export CSR/Private Key/Certificate

Verify Currently Installed Private Key and Certificates

Import Signed Certificate

View Certificate Files Uploaded for Import

SSL Requirements for Mac OS/CAS Communication

CAS Temporary Certificate Requirements for SSL Connection to Mac OS Agent

Installing the Root Certificate for Mac OS 10.2.x

Installing the Root Certificate for Mac OS 10.3.x

Installing the Root Certificate for Mac OS 10.4.x

Enable the Root User on Mac OS X

Obtaining the Root Certificate from the CAS

Troubleshooting Certificate Issues

CAS Cannot Establish Secure Connection to CAM

Private Key in Clean Access Server Does Not Match the CA-Signed Certificate

Certificate-Related Files

Synchronize System Time

Support Logs and LogLevel Settings

Changing the LogLevel for CAS Logs

Downloading CAS Support Logs


Administering CAS Certificates, Time, Support Logs


This chapter describes the following Clean Access Server administration tasks and topics:

Status Tab

Clean Access Server Direct Access Web Console

Manage CAS SSL Certificates

Synchronize System Time

Support Logs and LogLevel Settings

Status Tab

The Status tab of the CAS management pages displays high-level status information on which modules are running in the Clean Access Server.

Figure 13-1 CAS Management Pages Status Tab

IP Filter—An IP packet filter that analyzes packets to ensure that they come from valid, authenticated users.

DHCP Server—The CAS's internal DHCP (Dynamic Host Configuration Protocol) server.

DHCP Relay—The module that relays address requests and assignments between clients and an external DHCP server.

IPSec Server—The module for establishing a secure, IP Security-based channel between the CAS and a client device. The module encrypts and decrypts data passed between the client and server.

Active Directory SSO—The module that enables Active Directory Single Sign-On for authenticated Windows users.

Windows NetBIOS SSO—The module that enables Windows NetBIOS login for authenticated Windows users.

Clean Access Server Direct Access Web Console

The CAS management pages of the CAM web admin console (Figure 13-1) are the primary configuration interface for the Clean Access Server(s). However, each Clean Access Server has its own web admin console that allows configuration of certain limited Administration and Monitoring settings directly on the CAS (Figure 13-2). The CAS direct access web console is primarily used to download CAS support logs or r configure pairs of Clean Access Servers for High Availability. See Chapter 14, "Configuring High Availability (HA)" for details. If the CAS management pages become unavailable, you can also use the direct console interface for other functions such as managing SSL certificates for the CAS or performing system upgrade.

To access the Clean Access Server's direct access web admin console:


Step 1 Open a web browser and type the IP address of the CAS's trusted (eth0) interface in the URL/address field: https://<CAS_eth0_IP_address>/admin (for example, https://172.16.1.2/admin)

Step 2 Accept the temporary certificate and log in as user admin (default password is cisco123).

Figure 13-2 CAS Direct Access Web Admin Console—Cisco NAC-3300 Series


Note Because Cisco NAC network modules installed in Cisco Integrated Services Routers (ISRs) do not support high availability, the Failover tab is not available when you view the direct web admin console for a Cisco NAC network module.


Figure 13-3 CAS Direct Access Web Admin Console—Cisco NAC Network Module


NoteMake sure to precede the CAS IP address with "https://" and append it with "/admin"; otherwise you will see the redirect page for web login users.

For security purposes, Cisco recommends changing the default password for the CAS web console.


Note that almost all of the settings in the CAS web console can be configured via the CAS management pages in the CAM web admin console, with the exception of the Failover, Admin Password, and Support Logs. The CAS direct access web console provides the following Administration pages for the local CAS:

Network Settings—IP, DNS, and Failover (Cisco NAC-3300 Series only)

Software Update

SSL Certificates (Generate Temporary Certificate, Import Certificate, Export CSR/Private Key/Certificate)

Time Server

Admin Password

The Monitoring module of the CAS direct access console provides the following pages:

Active VPN Clients

Support Logs


Note For High Availability CAS pairs, any CAS network setting changes performed on an HA-Primary CAS through the CAS management pages or CAS direct access web console must also be repeated on the standby CAS unit through its direct access web console. These settings include updating the SSL certificate, system time, time zone, DNS, or Service IP. See IP Form, page 5-8 and Modifying High Availability Settings, page 14-23 for details.


Manage CAS SSL Certificates

This section describes the following:

SSL Certificate Overview

Typical CAS Certificate Steps for New Installs

Generate Temporary Certificate

Export CSR/Private Key/Certificate

Verify Currently Installed Private Key and Certificates

Import Signed Certificate

View Certificate Files Uploaded for Import

SSL Requirements for Mac OS/CAS Communication

Troubleshooting Certificate Issues

SSL Certificate Overview

The elements of Cisco NAC Appliance communicate securely over Secure Socket Layer (SSL) connections. Cisco NAC Appliance uses SSL connections for the following:

Between the CAM and the CAS

Between the CAM and the browser accessing the CAM web admin console

Between the CAS and end-users connecting to the CAS

Between the CAS and the browser accessing the CAS direct access web console

During installation, the configuration utility script for both the CAM and CAS requires you to generate a temporary SSL certificate for the server being installed (CAM or CAS). A corresponding private key is also generated with the temporary certificate.


Note Due to Java version dependencies in the system software, Cisco Clean Access only supports 1024- and 2048-bit key lengths for SSL certificates.



Note Cisco NAC Appliance does not support "wildcard" certificates.


This section discusses the following topics:

SSL Certificate Overview

CA-Signed Certificates

Intermediary Certificates

Non-Standard Certificates

Certificates for High Availability (HA) Pairs

Regenerating Certificates for DNS Name Instead of IP

Web Console Pages for SSL Certificate Management

CAM SSL certificate files are kept on the CAM machine, and CAS SSL certificate files are kept on the CAS machine. After installation, the CAM certificate can be managed from Administration > CCA Manager > SSL Certificate. The CAS certificate can be managed from either Device Management > CCA Servers > Manage [CAS_IP] > Network > Certs or from the CAS direct access console: Administration > SSL Certificate ( see Clean Access Server Direct Access Web Console).


Note For High Availability CAS pairs, any CAS network setting changes performed on an HA-Primary CAS through the CAS management pages or CAS direct access web console must also be repeated on the standby CAS unit through its direct access web console. These settings include updating the SSL certificate, system time/time zone, DNS, or Service IP. See Modifying High Availability Settings, page 14-23 for details.


CA-Signed Certificates

The CAS SSL certificate is used for communication between the CAS and the user's web browser and/or Clean Access Agent, and for communication between the CAM and CAS. In a production deployment, Cisco strongly recommends replacing the temporary certificate for the Clean Access Server with a Public CA-signed SSL certificate, for the following reasons:

The CAS certificate is visible to the end user. If the CAS has a temporary certificate, users have to explicitly accept the certificate from the CAS each time they login.

The root certificate needs to be trusted by the client machine.

With public certification authorities (Thawte, Verisign, etc.), the root already exists on the client machine.

For client machines running Windows Vista and/or Internet Explorer 7.0, Certificate Revocation List (CRL) checking is enabled by default. Cisco recommends obtaining a CA-signed certificate for the CAS if supporting Windows Vista/IE 7.0 client machines. For further details, see section Agent Error: "Network Error SSL Certificate Rev Failed 12057" of the Release Notes for Cisco NAC Appliance (Cisco Clean Access), Version 4.1(2).

For details Mac OS Agent certificates, refer to SSL Requirements for Mac OS/CAS Communication

For the Clean Access Manager, it is not necessary to use a CA-signed certificate and you can continue to use a temporary certificate, if desired. For details on managing SSL certificates for the CAM, see the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(2).


Note You cannot use a CA-signed certificate that you bought for the Clean Access Manager on the Clean Access Server. You must buy a separate certificate for each Clean Access Server.


Certification Authorities

A Certification Authority (CA) can be public (e.g. Thawte, Verisign) or private.

With a Public CA:

You submit your Certificate Signing Request (CSR) to the public CA and request a Webserver type or SSL type of certificate.

Your CA should provide you a certificate based on the CSR.

The CA's root or public key may also be requested.

Note that the CAM/CAS already have the public keys (root) of the most common public CAs.

With a Private CA:

You can submit your CSR to a private or local CA such as Microsoft CA server.

The private CA server provides the Certificate and root (Public key).

However, this root will need to be loaded to CAM/CAS.

Intermediary Certificates

When one or more Intermediary CAs are involved, you will have multiple root certificates or public keys. Each CA has its own root. The root/public key information of all certification authorities in the chain needs to be combined into one single file (for example, root.cer) before it can be uploaded into the CAS. To do this, open the root certificate of each CA and copy the information from each root cert into Notepad or a similar text editor. Include the "Begin Certificate" and "End Certificate' lines for each CA cert, and put each certificate one right after the other in the text file. Save this compiled root.cer file, then import it into the CAS as type "Root/Intermediate CA".

Non-Standard Certificates

Any certificate that is not provided by a public CA or that is not the self-signed certificate is considered a non-standard certificate by the CAS. If the CAM uses a non-standard certificate (for example, a certificate issued by Microsoft CA server), then an additional step is required. The root for the CAM's certificate needs to be imported into the CAS as type "Trust Non-Standard CA".

Certificates for High Availability (HA) Pairs

If you running HA-CAS pairs, you must generate the CSR for the Service IP of the HA pair and import the CA-signed certificate into one of the HA pairs (e.g. CAS-1). After that, the certificate information, i.e. the Private Key, Certificate and Root, will need to be exported from CAS-1 and imported into CAS-2. Refer to Chapter 14, "Configuring High Availability (HA)" for more information.

Regenerating Certificates for DNS Name Instead of IP

If planning to regenerate certificates based on the DNS name instead of the IP address of your servers:

When you are generating a CSR for signing, always export and save the private key to a secure location (for safekeeping and to have the private key handy). Make sure the CA-signed certificate you are importing is the one with which you generated the CSR and that you have NOT subsequently generated another temporary certificate. Generating a new temporary certificate after you have exported the CSR will create a new private-public key combination, and the new private key will no longer match the CA-signed certificate.

When importing certain CA-signed certificates, the system may warn you that you need to import the root certificate (the CA's root certificate) used to sign the CA-signed certificate, or the intermediate root certificate may need to be imported.

Make sure there is a DNS entry in the DNS server.

Make sure the DNS address in your Clean Access Server is correct (see Configure DNS Servers on the Network, page 5-16).

For High-Availability (failover) configurations, use the DNS name for the Service IP (virtual DNS).

Cisco recommends rebooting after you generate a new certificate or import a CA-signed certificate.

When using a DNS-based certificate, if it is not CA-signed, the user is typically prompted to accept the certificate.

Typical CAS Certificate Steps for New Installs

For new installations, the typical steps for managing the CAS certificate are as follows:


Step 1 Synchronize time
After CAM and CAS installation, make sure the time on the CAM and CAS is synchronized (within 3-5 minutes) before regenerating the temporary certificate on which the Certificate Signing Request will be based. See the next section, Synchronize System Time, for details.

Step 2 Check DNS settings for the CAS
If planning to use the DNS name instead of the IP address of your servers for CA-signed certs, you will need to verify the CAS settings and regenerate a temporary certificate. See Regenerating Certificates for DNS Name Instead of IP for details. For HA systems, you'll need to regenerate the certificates based on Service IP (see Generate Temporary Certificate).

Step 3 Generate Temporary Certificate
During initial CAS installation/configuration, a temporary certificate and private key are automatically generated. After you have synchronized the time and DNS settings on the CAS, you can regenerate the temporary certificate (and private key) with the updated parameters to create the Certificate Signing Request.

Step 4 Export (Backup) the private key to a local machine for safekeeping/backup.
Always back up the private key corresponding to the current temporary certificate to a local hard drive for safekeeping before you generate and export the Certificate Signing Request. See Export CSR/Private Key/Certificate.

Step 5 Reboot the Clean Access Server.
A reboot is required after certificates are regenerated.

Step 6 Export (save) the Certificate Signing Request (CSR) to a local machine.
See Export CSR/Private Key/Certificate.

Step 7 Send the CSR file to a Certification Authority (CA) authorized to issue trusted certificates.

Step 8 After the CA signs and returns the certificate, import the CA-signed certificate to your server.
When the CA-signed certificate is received from the CA, upload it as PEM-encoded file to the CAS temporary store. See Import Signed Certificate.

Step 9 If necessary, upload any required intermediate CA certificate(s) as a single PEM-encoded file to the CAS temporary store (see Intermediary Certificates).

Step 10 Click Verify and Install Uploaded Certificates to verify the entire certificate chain and private key in the temporary store and install the verified certificates to the CAS.

Step 11 Reboot the Clean Access Server.
Cisco recommends rebooting when you generate a new certificate or import a CA-signed certificate.

Step 12 Test as a client accessing the Clean Access Server.


Generate Temporary Certificate

The following procedure describes how to generate a new temporary certificate for the CAS. You can regenerate a temporary certificate with all the proper parameters to create Certificate Signing Request (CSR) suitable for submission to a Certification Authority (CA). See Regenerating Certificates for DNS Name Instead of IP for additional details.


Caution Cisco recommends backing up the current private key for the currently installed certificate prior to generating any new certificate, as generating a new certificate also generates a new private key. See Export CSR/Private Key/Certificate for steps.


Step 1 Go to Device Management > CCA Servers > Manage [CAS_IP] > Network > Certs.

Step 2 If not already selected, choose Generate Temporary Certificate from the Choose an action dropdown menu.

Figure 13-4 Certs—Generate Temporary Certificate

Step 3 Type appropriate values for the form fields:

Full Domain Name or IP - Either the fully qualified domain name (FQDN) or the IP address of the CAS for which the certificate applies, for example: caserver.<your_domain_name>.

If using an IP-based certificate, generate the certificate based on the Trusted Interface IP address (eth0) of the CAS.

If using a domain name, make sure that your DNS server can resolve the "Full Domain Name" entered.


Note To support the Mac OS Clean Access Agent, the CAS/CAM must use the FQDN as the "subject" DN on the certificate (this is the "Full Domain Name or IP" on the CAS/CAM console). An IP address is not allowed.


Organization Unit Name - The name of the unit within the organization, if applicable.

Organization Name - The legal name of the organization.

City Name - The city in which the organization is legally located.

State Name - The full name of the state in which the organization is legally located.

2-letter Country Code - The two-character, ISO-format country code, such as GB for Great Britain or US for the United States.

Step 4 When finished, click Generate. This generates a new temporary certificate and new private key.

Step 5 Verify the Current SSL Certificate Domain: <IP or domain name> field at the bottom of the form. This displays the IP address or domain name of the SSL certificate you just generated. Make sure that your DNS server can resolve the "Full Domain Name" you entered.

Step 6 Reboot the CAS (under Network > IP | Reboot). A reboot is required after certificates are regenerated.


Note The Current SSL Certificate Domain: <IP or domain name> field at the bottom of each form displays the IP address or domain name of the current SSL certificate being used to access the web console page displayed. For example, if you are accessing the SSL Certificate management pages of a CAS, the domain name or IP address that is on the SSL certificate of that CAS will be shown. If accessing the SSL Certificate management pages of the CAM, the domain name/IP on the SSL certificate of the CAM will be shown.


Export CSR/Private Key/Certificate

Exporting a CSR generates a PEM-encoded PKCS#10-formatted Certificate Signing Request suitable for submission to a certificate authority. The CSR will be based on the temporary certificate and private key currently in the keystore database. Before you send the CSR, make sure to export the private key to a local machine to back it up for safekeeping.

1. Go to Device Management > CCA Servers > Manage [CAS_IP] > Network > Certs (Figure 13-5).

Step 7 Choose Export CSR/Private Key/Certificate from the Choose an action dropdown menu.

Figure 13-5 Certs —Export CSR/Private Key/Certificate

Step 8 Create a backup of the private key used to generate the request by clicking the Export button for Currently Installed Private Key (A) in the Export CSR/Private Key/Certificate form. You are prompted to save or open the file (see Filenames for Exported Files). Save it to a secure location.


Note Cisco Clean Access only supports 1024- and 2048-bit key lengths for SSL certificates.


Step 9 Click Export CSR (B). A certificate signing request file for the CAS is generated and made available for downloading (see Filenames for Exported Files).


Note This step will generate a certificate request based on the currently installed (temporary) certificate and private key pair. Make sure these are the ones for which you want to submit the CSR to the certificate authority.


Step 10 Save the CSR file to your hard drive (or Open it immediately in a text editor if you are ready to fill out the certificate request form). Use the CSR file to request a certificate from a certificate authority. When you order a certificate, you may be asked to copy and paste the contents of the CSR file into a CSR field of the order form.

Step 11 When you receive the CA-signed certificate back from the certification authority, you can import it into the Clean Access Server as described in Import Signed Certificate.
After the CA-signed cert is imported, the "currently installed certificate" is the CA-signed certificate. You can always optionally Export the Currently Installed Certificate if you need to access a backup of this certificate later.


Note The Current SSL Certificate Domain: <IP or domain name> field at the bottom of each form displays the IP address or domain name of the current SSL certificate being used to access the web console page displayed. For example, if you are accessing the SSL Certificate management pages of a CAS, the domain name or IP address that is on the SSL certificate of that CAS will be shown. If accessing the SSL Certificate management pages of the CAM, the domain name/IP on the SSL certificate of the CAM will be shown.


Filenames for Exported Files

File names for SSL Certificate files that can be exported from the CAS are as follows:

File Name 1
Description

secsmart_csr.pem

CAS Certificate Signing Request (CSR)

secsmart_key.pem

CAS Currently Installed Private Key

secsmart_crt.cer 2

CAS Currently Installed Certificate

1 For release 3.6.0.1 and below filename extensions are .csr instead of .pem.

2 For release 3.6(1) only, the filename is secsmart_crt.pem.


Verify Currently Installed Private Key and Certificates

You can verify the following files by viewing them under Device Management > CCA Servers > Manage [CAS_IP] > Network > Certs | Export CSR/Private Key/Certificate (Figure 13-5):

Currently Installed Private Key

Currently Installed Certificate

Currently Installed Certificate Details

Currently Installed Root/Intermediate CA Certificate

Currently Installed Root/Intermediate CA Certificate Details


Note You must be currently logged into your web console session to view any certificate files.


On the CAS, if a particular file is not currently installed (for export) or not uploaded (for import), a dialog message "Unable to read certificate from Clean Access Server" will appear when you click the View or Details button. For example, if only a temporary certificate is present on the CAS, this message will appear if you click the View/Details buttons for "Root/Intermediate CA" or "Currently Installed Root/Intermediate CA" on the Import and Export forms, respectively.

Clicking View for "Currently Installed Private Key" brings up the dialog shown in Figure 13-6 (BEGIN PRIVATE KEY/END PRIVATE KEY).

Figure 13-6 View Currently Installed Private Key

Clicking View for "Currently Installed Certificate" brings up the dialog shown in Figure 13-7 (BEGIN CERTIFICATE / END CERTIFICATE).

Figure 13-7 View Currently Installed Certificate

Clicking Details for "Currently Installed Certificate" brings up the dialog shown in Figure 13-8 ("Certificate:"). The Currently Installed Certificate Details form provides an easy way to verify whether you have a temporary or CA-signed certificate. The most important fields to check are:

Issuer—Who signed the current certificate. The temporary certificate generated during installation will have the Issuer information shown in Figure 13-8.

Validity—The creation date ("Not Before:") and expiry date ("Not After":) of the certificate.


Note The time set on the CAS must fall within the creation date/expiry date range set on the SSL certificate of the CAM. The time set on the user machine must fall within the creation date/expiry date range set on the SSL certificate of the CAS.


Subject—The server and organizational information you entered when you generated the temporary certificate.

Begin Certificate/End Certificate—The actual certificate is displayed in this section. It is identical to the information shown when you click View "Currently Installed Certificate".

Figure 13-8 View Currently Installed Certificate Details (Example Temporary Certificate)

Clicking View or Details for "Currently Installed Root/Intermediate CA Certificate" will bring up similar dialogs for the root or intermediate certificates you have installed on your CAS.

Import Signed Certificate

If you have received a CA-signed PEM-encoded X.509 certificate for the Clean Access Server, you can import it into the Clean Access Server as described here. Before starting, make sure that the root and CA-signed certificate files are in an accessible file directory location. If using a certificate authority for which intermediate CA certificates are necessary, make sure these files are also present and accessible.


Step 1 Go to Device Management > CCA Servers > Manage [CAS_IP] > Network > Certs (Figure 13-9).

Step 2 Choose Import Certificate from the Choose an action dropdown menu.

Figure 13-9 Certs —Import Certificate

2. Click the Browse button next to the Certificate File field and locate the certificate file on your directory system.


Note Make sure there are no spaces in the filename when importing files (you can use underscores).


Step 3 Select the File Type from the dropdown menu:

CA-signed PEM-encoded X.509 Cert — Select this option to upload the PEM-encoded CA-signed certificate.

Root/Intermediate CA — Select this option to upload the PEM-encoded intermediate CA certificate or root certificate. To install chained certificates (i.e. multiple intermediate CA files):

a. If the certificate chain is using a different file format (e.g. .p7b), you must convert the chain to PEM format first.

b. Copy and paste the root and intermediate certificate information into a single file, then upload that as the Intermediate CA PEM-encoded file to the CAS.


Note Only one Intermediate CA file can be uploaded to the CAS, and it must be in PEM format.


Private Key — Select this option if you need to upload the Private Key for the CAS (from backup). Typically, you only need to do this if the current Private Key does not match the Private Key used to create the original CSR on which the CA-Signed certificate is based.

Trust Non-Standard CA — On the CAS, select this option if uploading a certificate needed for communication between the CAM and CAS that is signed by a non-standard organization. For example, you may have a non-standard certificate for the CAM that is signed by your institution (e.g. university), but a CA-signed certificate from VeriSign for your CAS. If the Clean Access Manager certificate is signed by a CA that is not well known, import the CA cert using the Trust Non-Standard CA option to have it accepted. The Clean Access Server must be rebooted for this to take effect.

Step 4 Click Upload to upload the certificate file to the temporary store on the Clean Access Server.

Step 5 Click Verify and Install Uploaded Certificates to verify the entire certificate chain and private key in the temporary store and install the verified certificate files to the correct locations in the CAS. If any files are missing, errors will be displayed indicating which files need to be uploaded. For example, if an intermediate CA certificate is required for the certificate authority you are using, upload it to the CAS temporary store in order for the certificate chain to be verified and installed on the CAS.


Note Neither the CAM nor CAS will install an unverifiable certificate chain. You must have delimiters (Begin/End Certificate) for multiple certificates in one file, but you do not need to upload certificate files in any particular sequence because they are verified in the temporary store first before being installed.


Step 6 If you try to upload a root/intermediate CA certificate for the CAS that is already in the list, you may see an error message "this intermediate CA is not necessary" after you click the Verify and Install Uploaded Certificates button. You must Delete the uploaded Root/Intermediate CA in order to remove any duplicate files.

Step 7 Reboot the CAS (under Network > IP | Reboot). Cisco recommends rebooting when you generate a new certificate or import a CA-signed certificate.


Note The Current SSL Certificate Domain: <IP or domain name> field at the bottom of each form displays the IP address or domain name of the current SSL certificate being used to access the web console page displayed. For example, if you are accessing the SSL Certificate management pages of a CAS, the domain name or IP address that is on the SSL certificate of that CAS will be shown. If accessing the SSL Certificate management pages of the CAM, the domain name/IP on the SSL certificate of the CAM will be shown.


View Certificate Files Uploaded for Import

You can verify certificate files you have uploaded to the temporary store for import into the CAS under Device Management > CCA Servers > Manage [CAS_IP] > Network > Certs | Import Certificate (Figure 13-5), as follows:

Uploaded Private Key

Uploaded CA-Signed Certificate

Uploaded CA-Signed Certificate Details

Uploaded Root/Intermediate CA Certificate

Uploaded Root/Intermediate CA Certificate Details


Note You must be currently logged into your web console session to view any certificate files.


On the CAS, if a particular file is not currently installed (for export) or not uploaded (for import), a dialog message "Unable to read certificate from Clean Access Server" will appear when you click the View or Details button. For example, if only a temporary certificate is present on the CAS, the message will appear if you click the View/Details buttons for "Root/Intermediate CA" or "Currently Installed Root/Intermediate CA" on the Import and Export forms, respectively.

SSL Requirements for Mac OS/CAS Communication

For the Mac OS Clean Access Agent to communicate with the Clean Access Server, the SSL communication between the Agent and CAS must meet certain requirements. The CAS must have one of the following:

A valid name-based CA-signed certificate (from a trusted Certificate Authority)

A name-based temporary certificate that meets the requirements described below


Note Ensure DNS can also resolve all name-based certificates.


CAS Temporary Certificate Requirements for SSL Connection to Mac OS Agent

If using a temporary certificate for the CAS, make sure the following are in place:


Step 1 The CAS/CAM must use a fully qualified domain name (FQDN) as the "subject" DN on the certificate (this is the "Full Domain Name or IP" on the CAS/CAM console). An IP address is not allowed. This may require regenerating the certificate on your CAS. (See Generate Temporary Certificatefor details.)

Step 2 On the Mac OS machine, the root certificate which is used to sign the temporary certificate must be installed in the X509 Anchors in Keychain Access application. To do this, use one of the following set of steps for the Mac OS version running on the machine:

Installing the Root Certificate for Mac OS 10.2.x

Installing the Root Certificate for Mac OS 10.3.x

Installing the Root Certificate for Mac OS 10.4.x

Step 3 The Mac OS machine must be able to correctly resolve the FQDN name via DNS. There are two approaches to this:

a. Add an entry into the DNS server which the Mac machine is using, or

b. For a test machine:

1. Enable your root account as described in Enable the Root User on Mac OS X

2. Edit the /etc/hosts file on the Mac machine by running sudo vi /etc/hosts to add a new domain lookup entry.



Caution Because the CAS/CAM use the full domain name, you cannot use an IP address in the certificate. You must use the domain name instead.


Caution Make sure your machine's date and time are valid for the certificate. If the current date and time fall out of the range of the certificate, the Agent will not work.

Installing the Root Certificate for Mac OS 10.2.x

Use the following steps to import a root or CA certificate on a Macintosh running Mac OS X 10.2.


Note You must have administrative permissions on your computer in order to run these steps.



Step 1 Download the root certificate to your client machine (or desktop). See Obtaining the Root Certificate from the CAS for details.

Step 2 Make sure that the certificate is in privacy enhanced mail (PEM) format.


Note If the certificate is not in PEM format, you can use Microsoft Certificate Manager in the Office folder to change formats. Import the certificate, then use the PEM format to save the certificate.


Step 3 Click the Finder icon in the Dock. From the Go menu, choose Applications.

Step 4 Open the Utilities folder.

Step 5 Double-click the Terminal program.

Step 6 Type the following commands, and press the Enter key after each line. Replace cert_filename with the actual file name of your certificate.

cd ~/Desktop 
cp /System/Library/Keychains/X509Anchors ~/Library/Keychains 
certtool i cert_filename k=X509Anchors 
sudo cp ~/Library/Keychains/X509Anchors /System/Library/Keychains 

Step 7 You must enter an administrative password after you press Enter for the last Terminal command. Figure 13-10 illustrates these steps.

Figure 13-10 Installing Root Certificate on Mac OS 10.2


Note The 10.2 certtool cannot import a certificate into any keychain that does not reside in your ~/Library/Keychains directory. The method outlined here resolves this issue by copying the X509Anchors to ~/Library/Keychains, performing "certoool i" there, and then (as root) copying the resulting X509Anchors back to /System/Library/Keychains/. For additional reference information for importing the root certificate on Mac OS 10.2.x, see also: http://support.microsoft.com/default.aspx?scid=kb;en-us;887413 and http://lists.apple.com/archives/apple-cdsa/2004/Jul/msg00021.html


Installing the Root Certificate for Mac OS 10.3.x

Use the following steps to import a root or CA certificate on a Macintosh running Mac OS X 10.3.


Note You must have administrative permissions on your computer in order to run these steps.



Step 1 Download the root certificate to your client machine (or desktop). See Obtaining the Root Certificate from the CAS for details.

Step 2 Double click the root certificate to bring up the Add Certificates dialog (Figure 13-11).

Figure 13-11 Add Root Certificate on Mac OS 10.3

Step 3 Choose X509 Anchors from the Keychain dropdown menu

Step 4 Click OK.

Step 5 The root certificate is now added to the keychain of the X509 Anchors (Figure 13-12)

Figure 13-12 Root Certificate Added on Mac OS 10.3.x

Installing the Root Certificate for Mac OS 10.4.x


Note You must have administrative permissions on your computer in order to run these steps.



Step 1 Download the root certificate to your client machine (or desktop). See Obtaining the Root Certificate from the CAS for details.

Step 2 Click the Finder icon in the Dock.

Step 3 From the Go menu, choose Applications.

Step 4 Open the Utilities folder.

Step 5 Launch the Keychain Access application.

Step 6 Drag the root certificate to the Keychain Access application.

Step 7 In the Add Certificates dialog box, click X509 Anchors and click OK.

Step 8 The root certificate is added (Figure 13-13)

Figure 13-13 Root Certificate Added on Mac OS 10.4.x

Enable the Root User on Mac OS X


Note Ensure you are an administrator on the machine. You must have access to an account that has administrator privileges to perform the rest of these steps.



Step 1 Click the Finder icon in the Dock.

Step 2 From the Go menu, choose Applications.

Step 3 Open the Utilities folder.

Step 4 Open the NetInfo Manager utility.

Step 5 Click the lock in the NetInfo Manager window (or go to Security > Authenticate).

Step 6 Type your administrator account username and password and click OK.

Step 7 For Mac OS X 10.2 and later, choose Enable Root User from the Security menu (Figure 13-14).

Figure 13-14 Enable Root User

Step 8 Type a password for root to enable the root account. If you have not previously set a root password, an alert box may appear that says "NetInfo Error," indicating that the password is blank. Click OK.

Step 9 Type the root password you wish to use and click Set.

Step 10 Retype the password for verification and click Verify.

Step 11 The root user is now enabled.

Step 12 Click the lock again to prevent changes.



Note For additional reference, see http://docs.info.apple.com/article.html?artnum=106290#one.


For more details, see also section "Mac OS X Agent Dialogs (Authentication Only)" in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(2)..

Obtaining the Root Certificate from the CAS

Because Internet Explorer allows exporting of the CAS certificate, this section describes how to obtain the root certificate on a Windows system. Administrators can then transfer the certificate to their Mac via email as an attachment, FTP, or USB storage device.

If the temporary certificate has not yet been installed on the Windows system:

Figure 13-15 illustrates the steps to initially download the temporary certificate.

1. Open an IE browser and enter any address. The browser will redirect to the authentication page for web login.

2. Since the certificate has not been installed, the Security Alert dialog pops up from the browser. Click the View Certificate button in the Security Alert dialog.

3. Click the Details tab in the Certificate window that pops up.

4. Click the Copy to File button in the Details tab

5. Leave format option as DER encoded binary x.509 (.CER) on the Certificate Export Wizard and click Next to save the certificate on the Windows system.

6. Transfer the certificate to your Mac machine.

Figure 13-15 Download Certificate Option 1

If the browser already has the temporary certificate installed:

Figure 13-16 illustrates the steps to download the certificate if already installed on the system.

1. Open the IE browser.

2. Go to Tools > Internet Options. Click the Content tab then the Certificates button.

3. Click the Intermediate Root Certificate Authorities tab in the Certificates window.

4. Highlight the certificate issued by www.perfigo.com and click the Export button.

5. Choose a location on your Windows machine to save the certificate.

6. Transfer the certificate to your Mac machine.

Figure 13-16 Download Certificate Option 2

Troubleshooting Certificate Issues

There can be issues with Cisco NAC Appliance certificate management if there are mismatched SSL certificates somewhere along the certificate chain. Common problems on SSL certificates can be time-oriented (if the clocks are not synchronized on the CAM and CAS, authentication fails), IP-oriented (certificates are created for the wrong interface) or information-oriented (wrong or mistyped certificate information is imported). This section describes the following troubleshooting topics:

CAS Cannot Establish Secure Connection to CAM

Private Key in Clean Access Server Does Not Match the CA-Signed Certificate

Regenerating Certificates for DNS Name Instead of IP

Certificate-Related Files

CAS Cannot Establish Secure Connection to CAM

If clients attempting login get the following error message, "Clean Access Server could not establish a secure connection to the Clean Access Manager at <IPaddress or domain> (see Figure 13-17), this commonly indicates one of the following issues:

The time difference between the CAM and CAS is greater than 5 minutes.

Invalid IP address

Invalid domain name

CAM is unreachable

The time set on the CAM and the CAS must be 5 minutes apart or less. To resolve this issue:

1. Set the time on the CAM and CAS correctly first (see Synchronize System Time)

2. Regenerate the certificate on the CAS using the correct IP address or domain.

3. Reboot the CAS.

4. Regenerate the certificate on the CAM using the correct IP address or domain.

5. Reboot the CAM.

Figure 13-17 Troubleshooting: "CAS Cannot Establish Secure Connection to CAM"


Note If you check nslookup and date from the CAS, and both the DNS and TIME settings on the CAS are correct, this can indicate that the cacerts file on the CAS is corrupted. In this case, Cisco recommends backing up the existing cacerts file from /usr/java/j2sdk1.4/lib/security/cacerts, overriding it with the file from /perfigo/common/conf/cacerts, then performing "service perfigo restart" on the CAS.


Private Key in Clean Access Server Does Not Match the CA-Signed Certificate

This issue can arise if a new temporary certificate is generated but a CA-signed certificate is returned for the CSR (certificate signing request) generated from a previous temporary certificate and private key pair.

For example, an administrator generates a CSR, backs up the private key, and then sends the CSR to a CA authority, such as VeriSign.

Subsequently, another administrator regenerates a temporary certificate after the CSR has been sent. When the CA-signed certificate is returned from the CA authority, the private key on which the CA-certificate is based no longer matches the one in the Clean Access Server.

To resolve this issue, re-import the old private key and then install the CA-signed certificate.

Certificate-Related Files

For troubleshooting purposes, Table 13-1 lists certificate-related files on the Clean Access Server. For example, if the admin console becomes unreachable due to a mismatch of the CA-certificate/private key combination, these files may need to be modified directly in the file system of the Clean Access Server.

Table 13-1 Clean Access Server Certificate-Related Files  

File
Description

/root/.tomcat.key

Private key

/root/.tomcat.crt

Certificate

/root/.tomcat.csr

Certificate Signing Request

/root/.chain.crt

Intermediate certificate

/perfigo/common/conf/perfigo-ca-bundle.crt

The root CA bundle


Synchronize System Time

For logging purposes and other time-sensitive tasks (such as SSL certificate generation), the time on the Clean Access Manager and Clean Access Servers needs to be correctly synchronized. The Time form lets you set the time on the Clean Access Server and modify the time zone setting for the CAS operating system.

After CAM and CAS installation, you should synchronize the time on the CAM and CAS before regenerating a temporary certificate on which a Certificate Signing Request (CSR) will be based. The easiest way to ensure this is to automatically synchronize time with the time server (Sync Current Time button).


Note The time set on the CAS must fall within the creation date/expiry date range set on the CAM SSL certificate. The time set on the user machine must fall within the creation date /expiry date range set on the CAS SSL certificate.



Note For High Availability CAS pairs, any CAS network setting changes performed on an HA-Primary CAS through the CAS management pages or CAS direct access web console must also be repeated on the standby CAS unit through its direct access web console. These settings include updating the SSL certificate, system time/time zone, DNS, or Service IP. See Clean Access Server Direct Access Web Console and Modifying High Availability Settings, page 14-23 for details.


The time can be modified on the CAM under Administration > CCA Manager > System Time. See the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(2) for details.

To view the current time:


Step 1 Go to Device Management > CCA Servers > Manage [CAS_IP] > Misc > Time.

Step 2 The system time for the Clean Access Server appears in the Current Time field.

Figure 13-18 Time Form

There are two ways to adjust the system time—manually, by typing in the new time, or automatically, by synchronizing from an external time server.

To manually modify the system time:

Go to the Time form of the Misc tab and perform one of the following steps:

Type the time in the Date & Time field and click Update Current Time. The time should be in the form: mm/dd/yy hh:ss PM/AM.

Click the Sync Current Time button to have the time updated by the time servers listed in the Time Servers field.

To automatically synchronize with the time server:

The default time server is the server managed by the National Institute of Standards and Technology (NIST), at time.nist.gov. To specify another time server:

1. In the Time form of the Misc tab type the URL of the server in the Time Servers field. The server should provide the time in NIST-standard format. Use a space to separate multiple servers.

2. Click Update Current Time.

If more than one time server is listed, the CAS tries to contact the first server in the list when synchronizing. If available, the time is updated from that server. If it is not available, the CAS tries the next one, and so on, until a server is reached.

The CAS then automatically synchronizes the time with the configured NTP server at periodic intervals.

To change the time zone of the server system time:

1. In the Time form of the Misc tab, choose the new time zone from the Time Zone dropdown menu.

2. Click Update Time Zone.

Support Logs and LogLevel Settings

The Support Logs page on the Clean Access Server is intended to facilitate TAC support of customer issues. The Support Logs page allows administrators to combine a variety of system logs (such as information on open files, open handles, and packages) into one tarball that can be sent to TAC to be included in the support case. Administrators should download these support logs when sending their customer support request.

The Support Logs pages on the CAM web console and CAS direct access web console (Figure 13-19) allow you to configure the level of log detail recorded for troubleshooting purposes in /perfigo/logs. These web controls are intended as alternatives to using the CLI loglevel command to gather system information when troubleshooting.

For normal operation, the log level should always remain at the default setting (Severe). The log level is only changed temporarily for a specific troubleshooting time period—typically at the request of the customer support/TAC engineer. In most cases, the setting is switched from "Severe" to "All" for a specific interval, then reset to "Severe" after data is collected. Note that once you reboot the CAM/CAS, or perform the service perfigo restart command, the log level will return to the default setting (Severe).


Caution Do not leave the log level set at "All" or "Info" indefinitely, as this will cause the log file to grow quickly.


Note To optimize memory usage, CAS support logs page are only available from the CAS direct access console under "Monitoring." (They are not available from the CAS management pages.)


Changing the LogLevel for CAS Logs

If requested to do so by the TAC engineer, you can temporarily change the loglevel to obtain more troubleshooting details prior to downloading the support logs.


Step 1 Open the CAS direct access console (https://<CAS_eth0_IP_address>/admin).

Step 2 Go to Monitoring > Support Logs.

Step 3 Choose the CAS log category to change:

CCA Server General Logging: This category contains general logging events for this CAS not contained in the other three categories listed below. For example a user that logs in (needs to post request to the CAM) will be logged here.

CAS/CAM Communication Logging: This category contains the majority of relevant logs: CAM/CAS configuration or communication errors specific to this CAS. For example, if the CAM's attempt to publish information to this CAS fails, the event will be logged here.

SWISS Communication Logging: This category contains log events related to SWISS (proprietary communication protocol) packets sent between this CAS and the Clean Access Agent.


Note To discover the CAS, the Agent sends SWISS (proprietary CAS-Agent communication protocol) packets on UDP port 8905 for L2 users and port 8906 for L3 users. The CAS always listens on UDP port 8905 and 8906 and accepts traffic on port 8905 by default. The CAS will drop traffic on UDP port 8906 unless L3 support is enabled.The Agent performs SWISS discovery every 5 seconds.


Radius Accounting Proxy Server Logging: This category contains RADIUS accounting log events related to Single Sign-On (SSO) for this CAS when integrated with a Cisco VPN Server.

Step 4 Click the LogLevel setting for the category of log:

All: This is the lowest LogLevel, with all events and details recorded.

Info: Provides more details than the Severe LogLevel. For example, if a user logs in successfully an Info message is logged.

Severe: This is the default level of logging for the system. A log event is written to /perfigo/logs only if the system encounters a severe error, such as:

CAM cannot connect to CAS

CAM and CAS cannot communicate



Caution Do not leave the log level set at "All" or "Info" indefinitely, as this will cause the log file to grow quickly.

Downloading CAS Support Logs


Step 1 Open the CAS direct access console from a browser using https://<CAS_eth0_IP_address>/admin as the URL/Address.

Step 2 Go to Monitoring > Support Logs (Figure 13-19).

Figure 13-19 CAS Support Logs

Step 3 Specify the number of days of debug messages to include in the file you will download for your Cisco customer support request.

Step 4 Click the Download button to download the cas_logs.<CAS_IP_address>.tar.gz file to your local computer.

Step 5 Send this .tar.gz file with your customer support request.


Note To retrieve the compressed support logs file for the Clean Access Manager, go to Administration > CCA Manager > Support Logs. See the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(2) for details.