Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current Restore this Version View Page History

« Previous Version 6 Current »

arget release

Epic

Document status

DRAFT

Document owner

Trip Gilman

Designer

Tech lead

Technical writers

QA

Objective

Today SSL certificates are managed in several different places which makes updating existing certificates and issuing new certificates difficult and prone to errors. We currently have three separate certificate processes. Java based backend services use a password protected local key store to house certificates. The key store is maintained as part of the development code line and is distributed as part of the software’s package. Java services include:

  • Config Server

  • HIS

  • RMS

Core web based applications in AWS are fronted by a load balancer. We install the certificates into the Certificate Manager AWS service and apply those certificates to the load balancer using the AWS management console. The core web applications include:

  • App Manager

  • PopFlow

  • Data API

  • MediaBar

  • Connect API

  • Analytics

Queue Adapter is an outlier in that it follows the same process as the core web applications when deployed in AWS but has its own process when deployed on premise. When deployed on premise, Queue Adapter requires the installer to download an unsecured copy of the certificate and apply it to the Windows certificate manager. The installer must then assign the certificate to a specific port using Windows command line. Anyone with administrative access to the server can export the certificate and use it however they want.

Success metrics

Goal

Metric

Assumptions

Requirements

Requirement

User Story

Importance

Jira Issue

Notes

1

HIGH

2

 

 

 

 

 

User interaction and design

Open Questions

Question

Answer

Date Answered

SSL Run-Book

Convert DER to PEM Format

This process must be performed on a machine with OpenSSL installed. File extension might be .cer, .crt, or .der for the source file.

  1. For each certificate file in DER format run the command openssl x509 -in original.cer -inform der -outform pem -out new_name.cer

Convert Individual Certificates into .p7b

This process must be performed on a machine with OpenSSL installed

  1. Ensure certificate files are in PEM format by opening in a text editor. If the file appears to have special characters or does not start with “-----BEGIN CERTIFICATE-----” it is in the DER format and needs converted. See Convert DER to PEM Format before proceeding.

  2. Run the following command including a -certfile mycertfile.cer pair for every certificate file. There should be at least 2-3 certificate files but the number can be more than that.

  3. openssl crl2pkcs7 -nocrl -certfile certificate.cer -certfile intermediate.cer -out certificate.p7b

Convert .p7b and Private Key to .pfx (PKCS12)

This process must be performed on a machine with OpenSSL installed

  1. Convert the .p7b file to a single chained certificate openssl pkcs7 -print_certs -in certificate.p7b -out temp.cer

  2. Create combined .pfx from the certificate chain and the private key openssl pkcs12 -export -in certificate.cer -inkey cert.key -out final.pfx. It will ask for a password for the pfx. If this .pfx file is intended to be imported into a java keystore, such as omis.jks, you want to use the same password for the .pfx file as the target java keystore.

Import .pfx (PKCS12) into Java Keystore

This process must be performed on a machine with the full Java SDK installed. The Java Runtime does NOT have the required utilities. It is highly recommended to create a backup of the keystore prior starting this process

  1. If the certificate being imported is intended to replace an existing certificate, for example in the case the original certificate has expired, the existing certificate must be removed. You can see if the certificate is already present using keytool -list -keystore keystore.jks. The existing certificate can be removed using keytool -delete -alias alias_name -keystore keystore.jks.

  2. Import the .pfx file into the Java keystore using keytool -importkeystore -srckeystore final.pfx -destkeystore keystore.jks. This will import the key chain under the alias ‘1'. Although this will technically work, it makes it difficult to identify which certificate is which.

  3. Change the alias to match the CN of the certificate using keytool -changealias -alias 1 -destalias cn_name_of_cetificate -keystore keystore.jks

  4. Ensure everything is correct using keytool -v -list -keystore keystore.jks

Change Private Key Password

  1. keytool -keypasswd -alias [Alias name for private key] -keystore

Overview and Requirements

The purpose of this document is to give direction on how to update wildcard certs in use for the OM QA in an https deployment environment.

Required Items:

·       Administrative access and rights to hosted environment

·       New Cert and Password for cert

Reference material:

https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-configure-a-port-with-an-ssl-certificate

 Take the new wildcard cert and put it on the box.  Some Environments require Personal, others do not.  If you are unsure what folder to import the cert to, check to see where the current cert is installed.  You can do that by finding out the APPID (see page 5 for instructions) of the cert and then looking for the cert in Console.

Ex.

Add the Certificates Snap-in in MMC.exe.

 Import the Certificate to Folder you want (Personal, Trusted, Root Trusted etc).

Right click the cert you have placed on the box and chose Install PFX.  This will open the Certificate Import Wizard.

Note:  Make sure, when importing the cert, that the two below items are checked.

 Once the Cert is installed, navigate to the Folder you put it in.

Double click the cert and go to “Details”.  Scroll down to the “Thumbprints” section.  Copy out the QUID that is inside the thumbprint because it will be needed later.  It may not allow you to copy paste it out.

Find the Application ID of the current Certificate

Open a CMD line in administrator mode.

Ex.  netsh http show sslcert

Copy out the Application ID into a notepad, you will need it later.  Include the curly brackets.

 Now, you have the Application ID of the current cert and the QUID of the new cert.  We need to add the new QUID to the Application that has the old cert.

Note:  Make sure QA is off while performing this next step.

Go back to your Administrator CMD line.

Delete the cert that is already bound to the port you need to use, QA uses port 5001.

Ex.  netsh http delete sslcert ipport=0.0.0.0:5001

Now, we are going to re-attach the new cert to the old Application ID with the new Cert thumbprint.

Note:  “certhash” is the thumbprint you grabbed from the cert but with no spaces in it.  Make sure that when you copy in the certhash that there are no special characters from the import.  There is almost always a hidden space at the end of the number.  You can use Word or Notepad++ to see these errors.

Ex.  netsh http add sslcert ipport=0.0.0.0:5001 certhash=**** appid={***}

Restart QA service.