IFS Cloud requires secured communication (HTTPS) for all types of installation.
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 the 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 normally have the 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 a 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 a 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 to 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 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 are 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.
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.
An 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"
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 acts 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 is never visible.
By default, the certificate is only trusted by the 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 the company IT-department - The IT-department acts as self-signed CA - the CSR handling is 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.
- 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
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.
- Organization 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. 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.
Note - some Oracle RDBMS versions don't support all fields in an Extended ValidationCertificate - 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 Cloud 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 Cloud.
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 IFS Cloud 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
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 should be stored in a password protected container. It can also be added as clear text in the ifscloud-values.yaml. The certificate should fulfill:
- 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
If using a pfx file it should also fulfill:
- Third-party certificates must be imported into a valid PKCS #12 store (pfx file)
- The PKCS #12 store password must contain at least six characters, See password limitations here
Summary: Minimum to order from a Certificate Authority that will work for IFS Cloud.¶
- 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
- When the signed keys has returned from the CA they need to be merged into a PKCS #12 Truststore - normally named .Pfx, .p12 - - It is also possible to add the certs in clear text in the ifscloud-values.yaml or feed them as parameters to the installer (and store them in a preferred secrets vault)
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.
Note: The installer will generate a self-signed certificate automatically if one is not provided - this is intended for unsecure test environments only. All production grade systems should have a valid trusted certificate.
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.
See how to manually validate certificates in Troubleshoot SSL