Creating Certificates
Contents
Creating Certificates
There are several ways to create the certificates needed by the STS. The biggest distinction in the certificates for the purposes of deployment is self-signed and issued by Certificate Authority (CA).
Certificate Authority
This is a trusted entity between two or more parties. Organizations may have an internal CA (e.g. Microsoft Certificate Services) for which all internal workstations and servers will accept certificates from. In some cases, external CAs may be used due to the application being public and used by systems that cannot be remotely configured.
Self-Signed
Self-signed certificates are more appropriate for non-production environments. These can be generated by the administrator locally on the server or using tools (e.g. OpenSSL).
The main issue with self-signed certificates is that may not be trusted by the systems using them. For example, in a development environment a self-signed web server certificate may generate warning on the workstations testing the service. Or a service provider may have their login process report errors.
For the intents of encryption or digital signatures a self-signed certificate is technically valid; i.e. it will protect the data in the expected manner. The primary thing missing is assurance provided by a trusted entity (i.e. the Certificate Authority).
Basic Requirements for Certificates
- The private key should be at least 2048 bits in length; ideally 4096 bits or higher should be used. The longer the key, the more likely it is able to withstand cryptographic attacks.
- A current hash such as SHA256 or SHA512 should be used. MD5/SHA1 have been deprecated in most implementations.
- The common name for the certificate should be something valid and representative of the service being used. E.g. if the STS development is located at https://stsdev.hospital.org, then the common name should be “stsdev.hospital.org”. This ensures alignment in the overall configuration of the environment and prevents potential browser errors with mismatched names.
Corporate Encryption Polices
Administrators will typically adhere to certificate management practices as set by internal policies or procedures. These may indicate how certificates can be deployed
Private Keys
A private key should never be shared outside of the internal system. Your service provided should never require for you to send them their private key and vice-versa. Once that private key is in the hands of an untrusted party, the security (self-repudiation) of that encryption or signing key is void.
Click here what to provide your Service Provider.
Generating a Self-Signed Certificate for SAML Signatures
For the STS installation, a certificate must be used to digitally sign the SAML assertions. The STS requires access to the private key in order to perform that action.
OpenSSL is a great tool to generate certificates, but a quicker way to generate a test or development certificate is to use Onelogin’s SAML Tool .
Steps
- Use tool making sure you fill out the common name to match your STS instance, the bit key length of 2048 bits and a SHA256/SHA512 digest. Enter a good password (8-12 characters) and make note of it as it will be required again.
- Copy the generated contents of the “X.509 cert” textbox in a text editor (e.g. Notepad). Save the file with a name of your choice but with a CER extension; e.g. “hospital.cer”.
- Copy the generated contents of the “Private Key” textbox in a text editor (e.g. Notepad). Save the file with a name of your choice but with a KEY extension; e.g. “hospital.key” in the same location as the CER file in the previous step.
- You now need to generate a PFX (PKCS #12) that Windows server and the STS can process. Download and install.
- From the OpenSSL command prompt navigate to the folder where you stored your CER and KEY files.
- Enter the following command:
openssl pkcs12 -export -out hospital.pfx -inkey hospital.key -in hospital.cer
- You will be prompted for the password from step 1 as well requested to enter a new password to protect the PFX file.
