In order to use third-party certificates in your iChain infrastructure, you must request a certificate from a Certificate Authority (CA), have the CA sign the certificate, collect and export the certificate and its trusted root, and then import the certificate and its trusted root to the iChain Proxy Server.
The process sounds straightforward but because CA’s are not all consistent in terms of certificate format, problems often exist integrating third party certificates with iChain. In fact, it ranks consistently as one of the highest call generators into Novell iChain Technical Support team.
The following document attempts to describe the main problem scenarios encountered dealing with CA’s. It will describe certificate format, tools and tricks that will allow administrators to get almost (*) any third party certificate to work with iChain 2.3. The three main scenarios discussed will be integrating a signed 3rd party certificate that
- includes multiple intermediates and a trusted root certificate
- includes both an intermediate and trusted root certificate
- includes a PKCS#12 formatted file with all certificates bundled together
The most basic setup where a server certificate is signed by one trusted root is already documented in the iChain 2.3 docs online (http://www.novell.com/documentation/ichain23/index.html?page=/documentation/ichain23/ichain23/data/a4g2cv7.html) and will not be covered in this document.
(*) Certificates with subject or issuer name attributes encoded in UTF8 format will not currently work with the iChain 2.3 release (planned for June 2006).
To check whether your certificates have the issuer name or subject name fields encoded in UTF8, use the “certutil” utility referenced in the Prerequisites section of ‘Scenario 1′ below. The actual arguments to use with the tool are shown below:
where server_cert.cer is the server certificate you have received from your CA, and server_cert2.dmp is the output file that we will view with an editor.
The key sections of the output file are the ones that include either the issuer name or subject name. In the case where the certificate has no UTF-8 encoded information and will work with iChain, the subject or Issuer fields will show CERT_RDN_PRINTABLE_STRING, as highlighted below.
In the case where the certificate has UTF-8 encoded information and will NOT currently work with iChain, the subject or Issuer fields will show CERT_RDN_UTF8_STRING, as highlighted below.
Standard Certificate formats
Throughout this document, references to multiple certificate formats will be mentioned. Below is a very brief description of the most common formats CA generated certificates will use.
a) PEM encoding - Can contain all of private keys (RSA and DSA), public keys (RSA and DSA) and (x509) certificates. It stores data Base64 encoded DER format, surrounded by ascii headers, so is suitable for text mode transfers between systems.
-----BEGIN CERTIFICATE----- MIIEvDCCBCWgAwIBAgIQBWXQILzgvZ/Yq0T/DF9j4DANBgkqhkiG9w0BAQUFADCB jDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTAwLgYDVQQL b20vdnNsb2dvLmdpZjANBgkqhkiG9w0BAQUFAAOBgQAfd2Pw4dWhyHrmcbPxqVKG : : : 9TGhojnDNQov4umWxtiMEScsx7L7CnanN6qNCMdVcBGrZpTW8IsGwSD2Gjg8fIfb /NfVk00RP00+QuzdtbH911tkbqakrjJd5Ck8Nq/jF1FUlgzu5+35cDtcTYB2PD05 A8NmmxGCAbsKaNp/6Vk98w== -----END CERTIFICATE-----
b) DER encoding - Can contain all of private keys, public keys and certificates. It stored according to the ASN1 DER format. It is headerless i.e. Missing the —–BEGIN/END CERTIFICATE—– string at the beginning/end). The above PEM format is text header wrapped DER. DER is the default format for most browsers, as it is binary encoded.
MIIEvDCCBCWgAwIBAgIQBWXQILzgvZ/Yq0T/DF9j4DANBgkqhkiG9w0BAQUFADCB jDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTAwLgYDVQQL b20vdnNsb2dvLmdpZjANBgkqhkiG9w0BAQUFAAOBgQAfd2Pw4dWhyHrmcbPxqVKG : : : 9TGhojnDNQov4umWxtiMEScsx7L7CnanN6qNCMdVcBGrZpTW8IsGwSD2Gjg8fIfb /NfVk00RP00+QuzdtbH911tkbqakrjJd5Ck8Nq/jF1FUlgzu5+35cDtcTYB2PD05 A8NmmxGCAbsKaNp/6Vk98w==
c) PKCS#7 – An envelope that can store multiple certificates in PEM or DER format. See http://www.ietf.org/rfc/rfc2315.txt for detailed specifications. Does not include any certificate private keys.
d) PKCS#12 – Similar to PKCS#7, PKCS#12 is a standard for storing private keys and certificates securely ? it defines a file format commonly used to store private keys with accompanying Public key certificates protected with a password-based symmetric key. It is used in Mozilla and Microsoft Internet Explorer with their import and export options.
Server Certificate Installation
Scenario 1: Server Certificate returned from CA includes multiple intermediates and trusted root certificate
- Microsoft Windows XP Workstation SP1 or higher with the Latest Version of “certutil” for Non-Windows Server 2003 Computers. The Windows Server 2003 Administration Tools Pack can be downloaded from “http://www.microsoft.com/downloads/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&DisplayLang=en”
or Microsoft Windows 2003 Server
- All three x509 Root Certificates belonging to the trust chain either returned via mail or downloaded from the support web site of the Certificate Authority.
- x509 Server certificate which has been returned enclosed into a mail from the Certificate Authority (CA) in a PEM encoded format enclosed in the following two lines:
-----BEGIN CERTIFICATE----- MIIFHDCCBASgAwIBAgIBADANBgkqhkiG9w0BAQUFADCBjzELMAkGA1UEBhMCREUx DDAKBgNVBAgTA05SVzEUMBIGA1UEBxMLRHVlc3NlbGRvcmYxDzANBgNVBAoTBk5v dmVsbDEMMAoGA1UECxMDTlRTMRowGAYDVQQDExFOVFMtR2xvYmFsLVJvb3RDQTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBub3ZlbGwuY29tMB4XDTA1MTIwMTA5MjYy ............. ............. m6QrAqIi2nRFOlpQ9oH8FkQvkzp2Ys2n005YwfbbFjsBrj7SkKBI37kiBGN9o7Jw AS90EHPlftenguZ1rtqMbKU7bIVhWApYfP0lnACqqN0pr3vqogKyHAqQh843Hkxj vGl7B5uvW18hG356hCT7hw== -----END CERTIFICATE-----
- Import all certificates belonging to the trust Chain
Select (highlight) each certificate enclosed in your email response from the CA including the “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” lines and copy and paste the contents into a text editor.
- Save the trusted root certificate files as plain text documents with the extension “.CER” and the
- server certificate with extension “.TXT”. This will make sure that all trusted root certificates will be associated with file type “Security Certificate” (Crypto Shell Extension) allowing to import a certificate by running a “double click” on a “CER” file.
As a reference for this document, the
- server certificate (server_cert.txt above) is issued by the Intermediate certificate 1 (NTS-ServerCA.cer);
- Intermediate certificate 1 (NTS-ServerCA.cer) is issued by Intermediate certificate 2 (NTS-Global-ServerCA.cer);
- Intermediate certificate 2 (NTS-Global-ServerCA.cer) is issued by the trusted root certificate ((NTS-Global-RootCA.cer)
- double clicking on each created “CER” file (as shown above) or
- opening Windows Control Panel -> Internet Option -> Content tab -> Certificates -> Import and specifying the location of each of the CER files saved from the previous step.
Scenario 2: Server Certificate returned from CA includes both an intermediate and trusted root certificate
- After generating the CSR request (includes private/public key pair) from the iChain GUI ‘Certificate Maintenance’ TAB and hitting ‘Apply’, the administrator will have the option to ‘View CSR’. Selecting this option dumps the CSR information that needs to be sent over to the Certificate Authority issuing the server certificate.
- After sending the file to the CA, the CA will validate the request and create a signed response – a signed certificate envelope that contains many attributes: the certificate subject, the name of the issuer, key usage, info about your identity, the CA’s identity, and also the validity period. This response will be available via email or the Web. In both cases, the CA will offer a server certificate, including private key, and an intermediate and root certificate (for this scenario). In most cases the CA sends a new signed PEM to the customer based on the original CSR request. However, some CA’s also offer the option to download from their site a complete B64 including all certificates in the path.
- Next, the administrator must take the signed response and link it to the already created public/private key pair, created at the CSR stage above. The method used to link depends on the format of the signed response from the CA.
- In the case where a PEM file exists for all certificates (server, intermediate and root), use Notepad to open each certificate and cut and paste it into the relevant GUI fields below (Server certificate contents, Intermediate Certificate contents and Root Certificate contents). This GUI interface opens up when the ‘Store Certificate’ option is selected (under Certificate Maintanance TAB) for the certificate created in step 1 above.
- In the case where the Certificates are available in an email, cut and paste each certificate contents (including the —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– strings) into the relevant fields below.
- In the case where the certificates are available via download, go to the URL specific and save each certificate as a seperate file. There may be an option to save the full certificate chain in PKCS#7 format too and refer to Scenario 2 for more details on this. Using Windows Notepad, open each certificate saved as a file and cut and paste it into the relevant GUI fields below.
- No Trusted root certificate available
Certain Verisign root certificates are already installed into the iChain box (located in the sys:\etc\proxy\verisign subdirectory). If an administrator is importing a Verisign signed certificate, there may not be a need to cut and paste the root certificate into the ‘CA Certificate contents’ section above. As a best practice, Novell recommends that you include the trusted roots from your CA into this field, and therefor this option will not be enabled. Please contact your CA if no trusted root information is available.
- Include Intermediate certificate
This option is only available with iChain 2.3 Support Pack 3 (ic23sp3.exe) builds and greater. If the Third party certificate you are trying to import into the GUI is signed by an Intermediate CA, and not directly by the root, you need to include the intermediate and root CA into iChain so that the certificate path can be validated to the root.
Scenario 3: Server Certificate returned from CA includes PKCS#12 format certificate (including certificate chain and keys)
PKCS#12 – also known as PFX files. This format often contains all private keys, public keys and certificates required to apply it to iChain. It is stored in a binary format and requires a password to install. For certificates received in this format, the simplest way of installing them to iChain is to FTP them to the iChain server. The figure below shows the process required to do this:
- FTP to the MiniFTP server on iChain (default directory on server is /etc/proxy/appliance/config/user)
- Change Directory to the cert/backup directory
- Copy the file over from the FTP client with a PUT
- When the certificate is FTP’d across, the administrator then needs to import it into iChain. Selecting the Certificate Maintenance TAB on the iChain GUI, we will use the ‘Restore’ option to insert the new Certificate into iChain. In the ‘Certificate name’ field, enter the name of the cert FTPd across in the previous step, without the PFX entension. The password is the password of the private key for that Certificate.
The Restore function looks in the cert/backup firectory for backed up certificates in the PFX format and just restores them.
- Click ok followed by Apply to register the changes. The status should come back as ‘Active’ with No errors.
- Go to one of the accelerators in the iChain setup and under the ‘Certificate’ drop down menu, select the new imported Certificate
- Any secure communication to the iChain box after this last change is applied will use this certificate.
- http://www.faqs.org/rfcs/rfc3280.html – Published standard for Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
- http://www.novell.com/coolsolutions/appnote/2571.html – How to Renew a Novell Certificate that was issued by an External CA.