Working with 3rd Party Certificates and iChain 2.3



By: ncashell

December 9, 2005 3:59 pm

Reads: 167

Comments:0

Rating:0

Introduction

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

  1. includes multiple intermediates and a trusted root certificate
  2. includes both an intermediate and trusted root certificate
  3. 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.

Note that this document does not cover the renewal process for Server Certificates on iChain. That specific topic is covered in a separate cool solution at http://www.novell.com/coolsolutions/appnote/2571.html.

(*) 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

Prerequisites:

  • 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-----

Installation Steps:

  1. 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.

    1. Save the trusted root certificate files as plain text documents with the extension “.CER” and the
    2. 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.
    3. Example:

      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)

  2. Import all x509 trusted root certificates into your browser starting from the trusted root and working down to the Intermediate certificate that issued the Server certificate (see note below!) by either
    1. double clicking on each created “CER” file (as shown above) or
    2. 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.
  3. NOTE: It is extremely important that you install the trusted root certificate first, followed by the intermediate certificate 2, and finally intermediate certificate 1. In each case, the following graphic will be shown:
  4. Select the option ‘Install Certificate’ to import them into the Microsoft certificate store. Click next at following screen
  5. Choose “Automatically select the certificate store based on the type of Certificate” and click “Finish on the “Completing the Certificate Import Wizard Menu” as shown below.
  6. The last certificate you import should be the first Intermediate trusted root certificate (Intermediate Certificate 1 from above) in the trust chain. Open the “Certification Path” tab of this certificate in order to confirm all required certificates in the trust chain have been successfully that the complete trust chain has been stored and the “Certificate status” returns “OK”.
  7. Create a PKCS #7 envelope including all root certificates. In order export all certificate into a “PKCS#7″ envelope open the “Details” tab on the server certificate and click on the “Copy to File” button and click “Next” at the “Welcome to the Certificate Export Wizard” window to get the following screen
  8. Select the option “Cryptographic Message Syntax Standard – PKCS #7 Certificates (.PB7)” and check the “Include all Certificates in the certificate path if possible” option.Click on next and choose a file name like “RootChain” (without providing any extension)
  9. Use the “installed “certutil.exe (see Prerequisites section above) to convert the saved RootChain.b7b file into a PEM encoded format required by the iChain GUI.
  10. Open the iChain GUI and go to the Certificate Maintenance TAB where the original CSR request was made ie. select the certificate which you like to import from the “Certificate name list”
  11. Click on the “Store Certificate” button. This will open the following Certificate import Dialog
  12. Open the PEM encoded RootChain.txt file (created in step 10) using a text editor and copy the content into clipboard
  13. Paste the base 64 encoded RootChain from clipboard into the “CA Certificate content” windows
  14. Open the Server Certificate server_cert file (saved in 1.1 above) using a text editor and copy the content into clipboard
  15. Paste the base 64 encoded server_cert from clipboard into the “CA Certificate content” windows
    Note: Do NOT select the Option ‘No Trusted Root Certificate Available’ or ‘Include Intermediate Certificate’ (see scenario 2 for more details on these options). The above screen is only available after installing iChain 2.3 Support Pack 3.
  16. Select create to finalise the creation of the server certificate
  17. Once done, hit the “Apply” button to update the system
  18. Verify that the Server Certificate status is now be “active” with “no errors”
  19. Go to the accelerator on the iChain server that you want to link this new Server certificate to (Configure -> Web Server Accelerator GUI TAB) under the ‘Certificate’ drop down menu, select the new imported Certificate from the list of available certificates.

Scenario 2: Server Certificate returned from CA includes both an intermediate and trusted root certificate

  1. 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.
  2. 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.
  3. 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.
    Note:

    1. 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.

    2. 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.

  4. Apply the changes via the iChain GUI and make sure that the status returned is ‘active’ with no errors.

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:

  1. FTP to the MiniFTP server on iChain (default directory on server is /etc/proxy/appliance/config/user)
  2. Change Directory to the cert/backup directory
  3. Copy the file over from the FTP client with a PUT
  4. 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.

  5. Click ok followed by Apply to register the changes. The status should come back as ‘Active’ with No errors.
  6. Go to one of the accelerators in the iChain setup and under the ‘Certificate’ drop down menu, select the new imported Certificate
  7. Any secure communication to the iChain box after this last change is applied will use this certificate.

References:

  1. http://www.faqs.org/rfcs/rfc3280.html – Published standard for Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
  2. http://www.novell.com/coolsolutions/appnote/2571.html – How to Renew a Novell Certificate that was issued by an External CA.
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags:
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Comment