Foundation1 / Installation Guide / Installing Fresh System / Planning Installation / Security Considerations / Certificates / This page

Certificate handling

Overview

IFS Applications requires secured communication (HTTPS) for all types of installation. Normally the HTTP Server acts as SSL termination proxy.

Certificates and Transport Layer Security (TLS) Basics

Certificates and Transport Layer Security (TLS) Basics Transport Layer Security (TLS) and it's predecessor Secure Socket Layer (SSL) are protocols used to ensure security of communication between two parties, commonly this means traffic between the client and the server. TLS aims to primarily provide privacy and data integrity between communicating applications. TLS connections have normally following properties:

• The connection is private because cryptography is used to encrypt the data transmitted.
• The identity of communicating parties can be verified through the use of public-key cryptography (digital certificates)
• Integrity is guaranteed by including a message authentication code into each transmitted message.

A digital certificate certifies the ownership of the public key used to identify the communicating parties. The certificates rely on trusted third-party certificate authorities (CA) to establish the authenticity of certificate owners.

Initially two random keys are generated when creating a new certificate - a private and a public key. The public key is used to create a CSR (Certificate Signing Request) file. The CSR normally contains identifiers like the Fully Qualified Domain Name (FQDN) of the server, but it can also contain variety of other information (such as company address, seat of operations, address etc.). A certificate with third-party trust (see self-signed certificates below) is normally signed by a Certificate Authority (CA) who is responsible for verifying the identify of the requester - this verification is represented by a digital signature on the certificate. Normally, each party stores these trusted CA root signatures certificates locally and use them to verify signatures passed to them in certificates when establishing a TLS communication session. Most keystores (such as Windows Certificate Store, Linux and Java) are delivered pre-loaded with CA root signatures and update automatically when Certificate Authorities change or publish new keys.

A self-signed CA is a special case where the initial random private key that is generated, is also signed locally on the same machine (thus they are called "self-signed certificates"). This type of self-signed certificate is never included in any preinstalled third-party CA signature lists. These self-signed certificates must always be added to the list of trust manually.

Chain of Trust

A chain of trust is designed to allow multiple parties to trust a system through a third party, without explicitly having to verify the identity of the party they're communicating with. This trust is established through digital signatures on certificates and is commonly referred to as "certificate trust" or "certificate path".
The the third party in this case, is a commercial provider, called Certificate Authority (CA). Comodo, GoDaddy, GlobalSign and Digicert are examples of such companies. in many cases the signing CA "root" certificate keys are split to several underlying intermediate keys, so protect the integrity of the root.
Each local client keystore contains the public key of such root certificate (often called Trusted Root Certificates). When establishing connection, the server sends over it's own certificate and a chain of any intermediate certificates necessary to verify the chain of signatures from the CA root to the server certificate. The client uses the locally stored trusted root CA public key to verify that the entire signature chain is correct. Once the handshake is successful, the encrypted connection is established
 

CA's Root Certificate
The CA's most important Certificate with a very secret private key, which is if compromised can lead to millions of certificates around the world being distrusted. It's this root CA the clients in fact trust.

CA's Intermediate Certificate
The CA issues some less vulnerable certificates that is used daily to sign server certificates. Each intermediate certificate only signs a limited amount of server certificates, then a new Intermediate Certificate is issued from the root certificate. When a CSR is sent to a CA the returned signed certificate actually holds both the signed server certificate and the CA's intermediate certificate. The Intermediate Certificates has a reference to the CA root certificate and is therefore just as trustworthy as the root certificate.

Server Certificate  
Holds the entire chain of trust. i.e. If you trust the root CA, you also trust the intermediate certificate and then this server certificate is trusted, since its signed by the intermediate certificate.

Example of IFS public certificates chain of trust. IFS has sent its CSR to DigiCert who signed the CSR with its intermediate certificate "DigiCert SHA2 Secure Server CA", so ifsworld.com is trusted by all who trust "Digicert"

Certificate Expiration

All certificates have expiration dates. A root certificate has roughly 30 years expiration time, and an intermediate certificate around 15 years. A server certificate is normally only valid for 1-5 years. Especially wildcard certificates tend to be short lived.

The result of this is that it's important to know when the server certificate of the IFS environment will expire. All client connections will fail if the server certificate has expired. Also keep in mind that any imported certificates used for outbound secure communication needs to be updated every 1-5 years.   

Different types of Server Certificate signing

The initially random private key that is generated for the IFS installation needs to be signed. This is done using a CSR (Certificate Signing Request). The CSR is always signed by a CA (normal CA or as self-signed CA), but the CA can be different things and depending on who act as a CA the behavior of the Certificates will be slightly different and are usable for different purposes. If the CSR is signed locally (self-signed) one might not even notice there is a CSR involved in the Certificate generation.

• Self-signed Certificate generated by IFS Installer (or manually) - the CSR handling never visible.

            By default, the certificate is only trusted by Application server itself, there is no chain of trust – the certificate is not even trusted by local browsers i.e. Windows/Linux truststores
                   i.e. any client need to manually download the certificate
->  installation testing

• Self-signed Certificate generated by company IT-department - The IT-department act as self-signed CA - the CSR handling often not visible.

By default, the CA is only trusted by all computers within the intranet (e.g. IFS CORPNET)
i.e. all browser clients within the intranet will be able to access the Appserver.
IT-department has installed certificate trust-chain on all machines installed by IT-department.
->  Dev/BnT

• A CA Certificate - ordered from a commercial Certificate Authority - The Commercial Certificate Authority act as CA and a CSR must be sent to the CA manually.

            Normally, the CA is trusted by Windows/Linux built in truststore – any clients that read that keystore will trust the Certificate.
                    i.e. all Web brower based clients will be able to access the Appserver.
                    All larger 3pp has built in certificate trust-chain towards all major Commercial Certificate Authorities
 ->  Test/Prod

Types of Certificates from a Certificate Authority

When ordering a signing of a Certificate from a commercial Certificate Authority as opposed to a self-signed Certificate Authority these different types of Certificates are often mentioned.

• Extended Validation (EV) SSL Cert

  Used primarily for Web Shops to validate the financial stability of the company holding the Web Shop.

• Organzation Validated (OV)
  Validates the organization holding a Web site.

• Domain Validated (DV)
  Just validates that the URL is tied to the company named in the certificate.

• Code Signing

  Validates that the code signed with this certificate  is tied to the company named in the certificate.

The requirement from IFS side is a Domain Validated Server Certificate. Normally a Domain Validated Server Certificate can be used for code signing with F1mage in the installer. The installer will not warn if the OHS certificate is used for client signing by F1mage even if the Certificate is not registered as a code signing certificate. Organization Validated and Extended Validation* is not required but will also work the same way.
The more accurate way of signing the IEE client with F1mage is to have a separate code signing certificate for IEE.

* Note - some Oracle RDBMS versions don't support all fields in an  Extended Validation Certificate - The installer will warn if it suspects doubtful parameters.

Hosts to include in the Certificate

The most important attribute in the certificate is the SAN (Subject Alternate Name) attribute. It should contain the Fully Qualified Domain Name (FQDN) of the IFS MWS host.
The Common Name (CN) is a deprecated attribute, but might be required by older integration systems, so it's better set to contain the Fully Qualified Domain Name (FQDN) of the host as well - but is not required by IFS Applications.

Normally using a Load Balancer, the certificate should be assigned to the Load Balancers FQDN where clients would expect a connection from. But this might vary depending on the Load Balancer configuration.

• If the Load Balancer is configured as a SSL Reverse Proxy then the certificate should be assigned to the Load Balancer host (FQDN)
• If the Load Balancer is configured as a SSL Tunnel, then the certificate should be assigned to the Application Server host (FQDN)

A clustered environment with more than one HTTP Servers and an external load balancer that forwards the https traffic without SSL offloading will require a certificate that handles several FQDN's. These two different types of certificates can be considered.

Multi-Domain certificate - SAN (Subject Alternate Name)
    Valid on a list of FQDN e.g.  host1.corpnet.com; host2.corpnet.com; host1.company.com
    The SAN attribute is set to e.g. host1.corpnet.com; host2.corpnet.com; host1.company.com

Wildcard Certificate
    Valid for all servers in a domain e.g. *.corpnet.com   Note: that host1.corpnet.com is valid, but host1.subnet.corpnet.com is not valid for a *.corpnet.com certificate.
    The SAN attribute is set to e.g. *.corpnet.com

Securely packaged certificates/keys

The keys in the certificates are sensitive information, so it needs to be stored in a password protected container. The IFS Installer will only import secure certificate stores that fulfill:

• Third-party certificates must be imported into a valid PKCS #12 store
• The PKCS #12 store password must contain at least six characters
• The complete Chain of Trust, including the CA Root Certificate, must be included into the PKCS #12 store
• The certificate must be a Server Certificate

Summary: Minimum to order from a Certificate Authority that will work for single node IFS Applications.

• Create a private and public key and send a CSR to one of the global Certificate Authorities - follow their instructions.
• Choose a Domain Validated Certificate (also commonly called Server Certificate)
• The Common Name (CN) = Subject Alternate Name (SAN) = FQDN
• The certificate should have code signing capability if used to sign the IEE client. Or a separate code signing sertificate is used to sign the IEE client with F1Mage.
• When the signed keys has returned from the CA they need to be merged into a PKCS #12 Truststore - normally named .Pfx, .p12

Manually create a Self-signed certificate

If you require a special Self-Signed Certificate with specific attributes these are the commands to generate a Self-Signed Certificate for host host1.mycompany.com.
Keytool is a tool in the java jre distribution, so a path to your local java_home is required to run these commands.

It's recommended to use keysize 2048 and use key algorithm RSA for the Certificates used in IFS systems.

CMD> keytool -genkey -alias MyCert -validity 1825 -keystore MyCertFile.jks -keysize 2048
             -keyalg RSA -dname "CN=*.mycompany.com SAN=dns:host1.mycompany.com"
CMD> keytool -importkeystore -srckeystore MyCertFile.jks -destkeystore myCert.p12 
             -deststoretype PKCS12 -srcstorepass MySecretPassword

Keytool don't support making Wild Card Self-Signed certificate with the SAN attribute set. The 3pp tools like MakeCert, Keystore Explorer or OpenSSL can be used.

Validating certificates

The IFS Installer has a validation button that will check the most vital requirements of a certificate like if it is stored in a valid certificate store and that it has a reference to a trusted CA. It will also check some other attributes.

See how to manually validate certificates in  Troubleshoot SSL