Identity Manager - Configuring ADS with SSL Certificate on the Provisioning Server
Article ID: 61927
Updated On:
Products
Issue/Introduction
Description:
How To - Configure ADS with SSL Certificate on the Provisioning Server?
Environment
Release: All versions
Component: IDMGR
Resolution
Configuring ADS with SSL Certificate on the Provisioning Server
Purpose
Provide the steps required to configure the Provisioning Server's Active Directory Option (ADS) with SSL for password management.
Steps
IIS:
Install IIS on both the ADS and Provisioning server (This is required to enable the web-based certificate issuance)
- From the Control Panel / Add-Remove Programs / Windows Components, select Application Server
- Select Internet Information Server, click details and select World Wide Web Service, click details and select only World Wide Web Server. You do not need FTP and MAIL (unless you intend to use this as the mail server for workflow.)
- Follow the wizard and take all defaults.
Certificate Services:
Install Certificates Services on the server that you will use as your Certificate Authority (CA). This may be the same as your Admin server but for the purposes of this tutorial, we will assume that this is a different server.
- From the Control Panel / Add-Remove Programs / Windows Components, select Certificate Services
- Click details and ensure that both Certificate Services CA and Web Enrollment Services are selected.
Download Root Certificate:
The root certificate allows clients to trust certificates signed by this root. Since we currently do not trust our CA, we need to import it's root certificate into our Trusted Root stores.
- Login to the system as an ADMINISTRATOR (preferably ETASLAPD)
- Open a browser to http://NameOfYourCAServer/certsrv
- Click on the link: Download a CA certificate, certificate chain, or CRL
- Click on the link: install this CA certificate chain
- Accept the default of putting in the Computer Account store.
Request a server certificate:
Now that we trust the CA, we will request a Server Certificate.
Notice that on the CERTSRV URL above, there is a Request a certificate link. That is NOT what we need. That link is for a personal certificate to identify the user not the server.
- From Control Panel / Administrative Tools, select Internet Information Services (IIS) Manager
- Expand your server name
- Expand Web Sites
- Right-click on the Default Web Site and select Properties
- Click on the Directory Security tab
- Click on the Server Certificate button at the bottom
- Select the option to Create New and Submit to CA
- Fill-in the information.
- NOTE: The State has to be spelled-up, i.e. New York (not NY)
- The last page should show you your CA server's name as the CA to submit the request to. Accept it. You will be returned to the properties page. Click OK.
You are done!
Troubleshooting:
You can check that the SSL cert is working by issuing the following command at the DOS prompt on your Admin server:
testldap -u Administrator IP password
******* Connect to:
Server: 1xx.2xx.3xx.4xx Port: 636 SSL : YES
ldap_sslinit() ..... Done ldap_connect() ..... ERROR: 81 LdapGetLastError(): 81 Error msg: Server Down Attempting manual connection to server:
... 45 bytes of handshake data sent ... 837 bytes of handshake data received ... 140 bytes of handshake data sent ... 35 bytes of handshake data received ... 35 bytes of handshake data sent ... 35 bytes of handshake data received
Handshake was successful
---------------------------------------------- Certificate Information ----------------------------------------------
Server subject: C=US, O=eTrust, OU=eTrust, CN= User ID Version: 2 Valid From: Date Range Valid To: Date Range Public key: RSA Signature algorithm: sha1RSA Serial number: 0CServer issuer: C=US, O=eTrust, OU=eTrust, CN= User ID
Error 0x800b0109 (CERT_E_UNTRUSTEDROOT) returned by CertVerifyCertificateChainPolicy! Error Description: A certification chain processed correctly but terminated in a root certificate not trusted by the trust provider. **** Error authenticating server credentials!
Protocol: SSL2 Cipher: RC4 Cipher strength: 128 Hash: MD5 Hash strength: 128 Key exchange: RSA Key exchange strength: 1024 Done
The output above shows two things:
- You needed to acquire the AD Domain with the FQDN
This can be resolved by either register this full qualified machine name on the DNS or manually configured through the Windows hosts file.
- The root certificate (or the Certificate Authority that signed the AD Domain Controller server certificate) was not trusted.
This can be resolved by obtaining and importing the root certificate using MMC/Certificate into the Local Computer Account
When it is done correctly, the testldap command's output should be as:
testldap -u Administrator FQDN password
******* Connect to: Server: TestServer Port: 636 SSL : YES
ldap_sslinit() ..... Done ldap_connect() ..... Done ldap_get_option() ..... Done Cipher Strength: 128 Hash Strength: 128
ldap_get_option() ..... Done Size Limit: 0 ldap_set_option() ..... Done ldap_get_option() ..... Done Keep Alive: 120 ldap_get_option() ..... Done
Reconnect: 1 ldap_search_s() ..... Done Default Naming Context: DC= ,DC= Root Naming Context: DC= ,DC= Bind DN: CN= ,CN= ,DC= ,DC= ,DC= ldap_simple_bind_s() ..... Done ******* Connection Established:
FAQs:
Q: I have used testldap and it is not giving consistent information. When my user id is used to run the command, the output shows that the root certificate is untrusted. When a domain administrator runs the command, the results show OK.
A: This is because you did not install the root certificate correctly. It was added to the admin's registry. You need to use MMC and add certificate snap-in that points to the Local Computer and add the certificate from there.
Q: I have used testldap and it is still presenting the old expired certificate for the Domain Controller.
A: You must reboot the Domain Controller in order for the OS to present the new certificate. This is not a function of the IM product, but a limitation of the Operating System.
Feedback
