Environment
Self Service Password Reset
SSPR 3.x
Situation
SSPR won't come up after expired wildcard certificate is replaced
Cannot access the SSPR page from workstations in the domain
Cannot open SSPR page from the SSPR server
Unable to open Tomcat hosted pages after adding or updating cert in Tomcat keystore
URL https:\\ourpage.ourdomain.com can no longer be loaded in a browser after updating certificate in keystorefile and restarting Tomcat
Resolution
Determine which certificate has expired. If the Tomcat (https) certificate has expired, continue with this document. If the LDAP certiciate has expired, see TID 7014955 (See the additional information section for an explanation of the two certificates involved with SSPR.)
This is most likely a Tomcat issue. Fix the HTTPS certificate in the Tomcat keystore.
This is most likely a Tomcat issue. Fix the HTTPS certificate in the Tomcat keystore.
NetIQ does not support Tomcat, but we have seen the following work successfully:
Option 1:
Delete the old ssprtomcat certificate from the Tomcat keystore and create a new one.
To delete the old certificate use the following command:
C:\Program Files (x86)\NetIQ Self Service Password Reset\jre7\lib\security>"%JAVA_HOME%"\bin\keytool -delete -alias ssprtomcat -keystore cacerts -storepass changeit
To create a new certificate use the following command:
"C:\Program Files (x86)\NetIQ Self Service Password Reset\jre7"\bin\keytool -genkeypair -alias ssprtomcat -keyalg RSA -dname "cn=sspr server, ou=sspr, o=support, c=NetIQ" -keypass changeit -keystore "C:\Program Files (x86)\NetIQ Self Service Password Reset\jre7"\lib\security\cacerts -storepass changeit
Option 2. Combine all of the Tomcat certificate files (such as those provided by a trusted certificate vendor) into a single certificate and replace the wildcard alias in the keystore with the new combined crt file. Do this because the certificate chain may break when intermediate certs are imported independently of the wildcard certificate.
Steps:
- Create a text file containing the new cert from whatever.crt. Append the contents from the GoDaddy bundle gd_bundle-something.crt.
- Run key tool command C:\Program Files\Java\jre7\bin>keytool -import -alias <name> -keystore "C:\Program Files\Java\jre7\lib\security\cacerts" -trustcacerts -file "C:\certs\<path>\combined.crt"
Option 3. Export the existing wildcard certificate from IIS on an existing server and convert it to a PKCS12# format. Then import it into the keystore along with the root and intermediate certificates from the certificate vendor.
Option 4. Start over with a fresh Tomcat instance and keystore.
- Open the tomcat\webapps directory and move sspr.war and the sspr directory to a safe place
- Use keytool to import a cert into a fresh keystore,
- Configure a fresh Tomcat instance for SSL.
- Move the existing SSPR directory into the new Tomcat folder.
Troubleshooting tip:
Verify that the cacerts file you are updating with keytool is the same cacerts file that Tomcat is using. To do this:
- look at the server.xml file in the Tomcat folder on the SSPR server it will probably be under C:\Program Files\Apache Software Foundation\Tomcat 6 or 7\bin\conf
- see where server.xml is pointing for the keystoreFile. Look for a section like this:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="${java.home}/lib/security/cacerts" <--- this should be the directory you point to with keytool
keystorepass="changeit" />
Additional Information
There are two certificates involved with SSPR. The HTTPS certificate and the LDAP certificate. The LDAP certificate is used to connect the SSPR server with the LDAP (e.g. AD or eDir) server , and the HTTPS certificate is used to connect to the web browser. These certificates have no relation to each other.
The LDAP certificate is managed by SSPR through the import function in the "Actions" menu in the SSPR configuration editor. The HTTP certificate is managed in the keystore, and used by Tomcat. SSPR doesn't know anything about nor do anything with the HTTP cert, other than to launch on top of Tomcat.
To test whether the problem is with SSPR or with Tomcat, try using https and open a page that is hosted on the Tomcat server other than SSPR (e.g. the Tomcat home page or iManager). If this doesn't work, then pursue the problem as a Tomcat / keystore certificate issue. (After all, if the tomcat home can't be seen over https there is no way SSPR or any other tomcat-hosted application will come up over https.) If the Tomcat home page does work over https, then look for problems with SSPR and the LDAP certificate.
Note: The certificates referenced in section 2.3.2 "Setting Up a Secure Channel Between the Application Server and the LDAP Server"
of the online documentation are the LDAP certificates, not the HTTPS certificates.
of the online documentation are the LDAP certificates, not the HTTPS certificates.