Secure HTTPS Communication with SSL Certificates

Concept and Benefits for project managers simply explained

When communicating via the Internet (e.g. between an ALM tool like Jira, ServiceNow or SAP Cloud ALM and Conigma Connect), encrypted communication via HTTPS is usually desired (HTTP would be unencrypted). This blog entry explains the concept behind this as a basis for our customers' project managers to plan the right internal resources for this.

In bidirectional communication, each of the two communication partners takes on either the client or the server role once, depending on the direction of communication. The certificate setup must therefore be performed twice, once in each direction.

Compared to unencrypted HTTP communication, HTTPS offers two major advantages:

1. Authentication: The client can ensure that the server is who it claims to be.

2. Encryption: The communication is not visible to third parties; only the two communication parties can decrypt the content.

The requirements necessary for secure communication must be met first and foremost by the server. It must present to the client a valid certificate. On that basis the encryption is set up. In addition, the server must possess the private key belonging to the certificate. In order to be "valid", a server certificate has to be signed by a trusted issuer (root CA). When configuring a server, it must be informed which certificate it has to present in the event of a connection request.

Trusted means here that the client trusts the issuer (i.e. the issuer's root certificate is installed in the client's certificate store). Common operating systems (Windows, Linux, etc.) already include the standard certificates of common issuers (e.g. Let's Encrypt, Verisign, Comodo) in their certificate store. For companies that act as their own (non-standard) root CA, it is necessary to include the root certificate in the client's certificate store.

A server certificate is always issued for a specific server and signed for this server, so it cannot be supplied by a software manufacturer. Important in this context is: For certificates you may receive private keys (.key file) or you may receive certificate files with integrated private key (.pfx file). It is absolutely necessary to keep these files secret, as all security features of an HTTPS connection can be compromised by unauthorized access to the key.

When configuring Conigma Connect, the corresponding certificate is entered in the configuration file. A common error is that a certificate without available private key is used, which leads to Conigma Connect not starting and displaying a corresponding error.

Another common error ist that the certificate does not contain the required purposes. Best practice is to include the following for a HTTPS server:

keyUsage = digitalSignature, nonRepudiation, keyEncipherment
extendedKeyUsage = serverAuth

nonRepudiation can be omitted if the Root CA does not provide it.