June 20, 2023

If you’ve ever configured a Rocket UniVerse or Rocket UniData (U2) product for SSL, you’ve likely come across the option to set ‘Authentication Strength’. The options are Strict and Generous. While that wording is descriptive enough to tell you that ‘Strict’ is probably better when it comes to security, what does it mean in real terms?

First, it’s important to know that secure communication these days is mostly done using a protocol called TLS (this includes U2). TLS, or Transport Layer Security, was launched in 1999 as an upgrade to the Secure Sockets Layer (SSL) version 3.0. TLS can be thought of as SSL 3.1 or 4.0. Some argue that the name was changed simply to avoid any legal issues with SSL’s original creator, Netscape. ‘SSL’ is still generally used to describe secure communications; the terms SSL and TLS are used interchangeably. This article is no exception.

If the systems communicating with each other are all U2 databases, you can simply set them all to the same strength, either all Strict or all Generous, and everything will communicate happily. This situation is less and less likely these days. We are usually required to share data between a wider and varied range of technologies. So, what about communications with non-U2 systems? You may have already tried to search for ‘Strict vs Generous SSL’ and come up empty. While these terms are quite user-friendly, they are unique to U2 and are not immediately translatable elsewhere. This article explains what they mean in terms that can be related to other SSL communication setups.

Security Context Records and Security Property Lists

You likely know what these are or at least when you need to use them. Both are essentially a package containing the security properties required to automate the SSL part of a connection. You add a certificate, a private key, and its password and then assign it to a connection stream like Telnet, ODBC or UniObjects. This is where the ‘Authentication Strength’ setting comes into play. You’ll see Security Context Records (SCRs) when configuring U2 SSL Telnet for example and you may see Security Property Lists (SPLs) when configuring U2 SSL ODBC or SBClient SSL sessions.

Fig 1.1 (top): U2 Extensible Administration Tool connected to UniVerse for Windows. The Security Context Record tab of the SSL Configuration task. 
Fig 1.2 (bottom): SBClient configuration window ‘Edit SSL Property List’.

Secure Connection Authentication Requirements

You also likely already know that, during the SSL connection handshake, the server sends its certificate to the client, and the client must validate the certificate. For the server certificate to be accepted, it must satisfy a set of requirements:

1. A well-formed certificate. Certificates have several characteristics. A well-formed certificate needs to conform to a certain standard (such as X.509) and use certain algorithms for its keys, signatures, and other properties. The validator (the process that accepts or rejects the connection) will have predetermined expectations regarding all of this based on a minimum level of security that it accepts.
2. Certificates have an expiry date; the incoming connection’s certificate must be within the date and time accepted by the validator.
3. The certificate cannot be on the Certificate Revocation List (CRL). A certificate can be ‘revoked’ by adding it to a CRL, meaning it can be intentionally excluded or disallowed. CRLs can be local or online. U2 allows you to specify CRL files in the CRL property of an SCR/SPL. You must download the CRLs from their respective CA sites.
4. Certificates are created for a particular server or site and need to include this, usually in the CommonName value. It can also sometimes be found in subjectAltName. The value in the certificate needs to match the address of the server: example.com or ourprodserver.ourcompany.com for example. U2 SCR’s and SPL’s can also allow the name to be specified in the PeerName value.
5. A complete and verified certificate-chain. The certificate itself, any intermediate certificates, and the root signing Certificate Authority (CA) certificate need to be verifiable by the validator. Some browsers/applications/devices do not require the intermediate certificates to be physically installed on the server, only the CA certificate. It is good practice to ensure any intermediate certificates are installed, however. This ensures compatibility with all clients. Provided all intermediate certificates and the root certificate can be verified, the certificate itself does not need to physically reside on the server.

Fig 2.1: Certificate-chain for the www.google.com website as seen through the Chrome browser’s Certificate Viewer. Found by clicking the padlock to the left of the site address, then ‘Connection is Secure’, then ‘Certificate is Valid’ (Chrome version 113.0, other releases may have a different path). Yellow: the site’s certificate, Red: the intermediate certificate or ‘Issuer’ of the site certificate, Blue: the CA Root certificate or ‘Issuer’ of the intermediate certificate, Green: also the CA Root certificate, the root certificate is seen as the ‘Issuer’ of itself – the beginning of the chain. 

Fig 2.2: Showing the certificate-chain with OpenSSL. The ‘s:’ indicates the ‘Subject’ (certificate) and the ‘i:’ indicates the ‘Issuer’. As you go up the chain you see the ‘Subject’ is the ‘Issuer’ of the next certificate in the chain. The ‘CN’ or ‘CommonName’ is the link. This differs slightly to the Chrome example in Fig 2.1 where the CN of the root certificate is the name of the Certificate Authority rather than the CA Certificate itself: GlobalSign Root CA and GTS Root R1 respectively. They are, however, showing the same certificates from the same website: www.google.com.

The Difference

Generous connections must adhere to requirements 1, 2, 3 and 4 listed above.

Strict connections must adhere to all five requirements.

So, really, the only difference between Strict and Generous is access to the certificate-chain. While this seems insignificant (one out of five criteria), the ability to verify a certificate against a CA root certificate is a big deal because it adds all-important ‘Trust’ to the connection. This is why ‘Generous’ is usually only recommended for test servers or internal systems that don’t interact with the outside world.

Self-signed Certificates

A self-signed certificate is one that is not part of a certificate-chain and has not been ‘signed’ by a Certificate Authority. Generally, a self-signed certificate is created to test a system before implementing a CA signed certificate when going live. A self-signed certificate is still a certificate, it just doesn’t come with the ‘trust value’ of a CA signed certificate. They are sometimes used on internal-only systems. A CA signed certificate usually comes at a cost whereas a self-signed certificate can be created for free with a locally installed tool like the U2 Extensible Administration Tool or OpenSSL directly.

Certificate Accessibility

A validator is essentially the ‘SSL part’ of a process that is accepting or rejecting the incoming connection (U2 uses OpenSSL to achieve SSL communication). These validators need to verify an incoming connection’s certificate chain. To do this a validator needs physical access to the signing certificates in the chain, not the incoming certificate itself. The most common method of providing access to these signing certificates is with a certificate store. There are different types of certificate store, but all are essentially the same: a repository of certificates. Windows and other operating systems have their own. Java has its ‘KeyStore’. And of course U2 has the ‘.u2rcs’ file.

Some connection configurations allow you to choose between the operating system certificate store and the U2 certificate store. Adding a certificate to the U2 store can be achieved using the ‘rcsman’ command. For the Windows certificate store simply right click the certificate file and “Install Certificate”. For other operating systems please check the appropriate documentation.

Fig 3.1 (Left): Using ‘rcsman’ on UniVerse for Windows to import a certificate called ‘mycert.cer’ into the U2 Certificate Store. Fig 3.2 (Right): Installing the ‘mycert.cer’ certificate into the Windows Certificate Store.

If your certificate has been signed by a well-known commercial Certificate Authority, their CA root certificate is potentially already in your certificate store as these are updated regularly. Remember, the certificate itself doesn’t need to be in the server’s certificate store but the rest of the certificate-chain does. So provided the CA root certificate and all intermediate certificates are there, a strict connection will be possible.

If you use a certificate store (OS or U2) for your SSL connection, and you are connecting to an SSL server that sends you a self-signed certificate, you must install it into the store you use before you start the connection. Or you must explicty specify it as CACertificate in your SCR/SPL.

If instead you are configuring an SSL server for others to access, and want to use a self-signed certificate for your server, you must pursuade all the clients to accept it by installing it into their certificate stores. You may find this difficult to achieve, especially for systems outside your orginisation.

So far, we mostly talked about authenticating an SSL server. The same desciptions are applicable to ‘Client Authentication’ where an SSL client must authenticate itself to the server by presenting its certificate.

Summary

SSL connections require a certificate. A certificate must be:

• Well formed using acceptable formats, algorithms, keys, signatures and other properties
• Inside an acceptable date and time range
• Not revoked via a Certificate Revocation List (CRL)
• For the correct site or server, containing the fully qualified server name in the CommonName, subjectAltName or PeerName as appropriate for the connection

Generous connections require the above. Strict connections require the above and that the certificate be:

• Part of a fully certified and verifiable certificate-chain

Certificates can be made accessible to validators (the part of the communication process that accepts or rejects a connection) by storing them in a certificate store. Another way to achieve this is to specify the chain explicitly in an SCR or SPL.

The U2 certificate store can be managed using the ‘rcsman’ utility.

Certificate stores usually come preloaded with the most common CA Root certificates, and these are usually updated when the operating system, browser, application, or device receives an update.

Strict and Generous are U2 terms to describe the level of security requirements of an SSL connection. Strict connections require everything a Generous connection requires plus access to the complete certificate chain. This is usually achieved by ensuring the necessary root and intermediate certificates are in the node’s certificate store.