Submit a ticketCall us

Get a crash course on Network Monitoring delivered right to your inbox
This free 7-day email course provides a primer to the philosophy, theory, and fundamental concepts involved in IT monitoring. Lessons will explain not only how to perform various monitoring tasks, but why and when you should use them. Sign up now.

Home > Success Center > Web Help Desk (WHD) > Web Help Desk Administrator Guide > Configure and manage authentication > Manage keys and certificates

Manage keys and certificates

 Updated April 15th, 2016

 

This section does not apply to deployments enabled with FIPS 140-2 cryptography. See Enable FIPS 140-2 compliant cryptography for information about creating CA and self-signed certificates in a new or existing FIPS deployment.

When a browser submits an HTTPS request to Web Help Desk, the SSL protocol requires the application to respond with a certificate to verify the authenticity of the server. The certificate contains a public key used for encryption and a digital signature from a Certification Authority (CA). The digital signature indicates which CA verified the authenticity of the server.

Trust certificates signed by CAs

Current Web browsers trust most certificates signed by large CAs (such as Verisign). You can also use certificates signed by smaller CAs. When a Web browser does not recognize the certificate CA, the Web browser prompts you to confirm your trust in the certificate.

After you confirm your trust, the Web browser uses the certificate's public key to encrypt information it sends to Web Help Desk. In turn, Web Help Desk decrypts the information using its private key. Similarly, Web Help Desk uses its private key to encrypt information sent to the Web browser, and the Web browser uses the public key received in the certificate to decrypt it.

Store keys and certificates

Web Help Desk stores its keys and certificates in a Java keystore located at <WebHelpDesk>/conf/keystore.jks.The open-source utility Portecle bundled with Web Help Desk provides a graphical user interface for administering the keystore on the Windows platform.

Generate a keypair and CSR

If you do not have a certificate for your server and are using the Windows platform, use Portecle to generate both a keypair and a Certificate Signing Request (CSR) to send to the CA. When completed, import the CA Reply certificate.

Import a certificate and private key to the keystore

If you currently have a certificate, import both the certificate and the primary key into the keystore. Portecle does not allow you to import a primary key by itself, so you must combine it with its certificate in a Public-Key Cryptography Standards (PKCS) #12 file (*.p12 or *.pfx). In each case, the keypair must be aliased as tomcat and both the keypair and the keystore must be protected by the password specified in the KEYSTORE_PASSWORD setting in the whd.conf file.

For more information about working with keys and certificates, see:

 
Last modified
11:14, 17 Feb 2017

Tags

Classifications

Public