Intermediate Certificates

Table of contents

• Introduction
• Problem
• Intermediate Certificates
• Solution
• Conclusion

In this article we will take a closer look at the topic of certificates and the consequences that a missing intermediate certificate can have. We will start with an error.

 

Introduction

Nowadays almost every website can be accessed via HTTPS and classic HTTP is no longer supported. But what does that actually mean? A website that you access via HTTPS is secured with a certificate. This means that the data traffic between your browser and the website is encrypted so that your entries and data do not travel through the Internet in plain text.

To do this, a website operator can have an SSL certificate set up by their host, which usually involves extra costs, or they can create certificates for the website themselves through public bodies, which usually involves a lot of effort. We therefore use the second method via "Let's Encrypt" and ensure that we have up-to-date certificates for the domain and subdomains every three months.

 

Problem

We were currently testing our own website API via ABAP when an error occurred while accessing the API. The error message was as follows:

SSL handshake with software-heroes.com:443 failed: SSSLERR_PEER_CERT_UNTRUSTED (-102)
Peer's X.509 certificate (chain) validation failed (missing trust?)

 

Further down in the error message we find further information about the error message and that the chain of certificates is incomplete:

ERROR: The chain of certificates is incomplete or untrusted, missing certificate of [AE:58:47:28] CN=dev.software-heroes.com

 

If we now check our website with an SSL Checker, we also receive a corresponding error message. However, this message does not apply to most browsers, but only becomes apparent when accessing the page via API, when the certificate or certificate chain is actually checked.

 

Intermediate Certificates

We can also quickly find further information about the chain of certificates that are relevant for registration via Let's Encrypt. The following diagram from the article shows this:

© letsencrypt.org

 

The root certificate is usually issued for a longer period of time and the key to it is stored offline so that the certificate is not compromised. If the key were compromised, any attacker could pose as a trustworthy website and give us, the user, a false sense of security. Below this there is a layer of certificates that do not last quite as long, usually 1-2 years; these "intermediate certificates" establish the connection from our website to the root certificate. This chain should also be known to a verifying body (website, software, APIs) so that it can check the authenticity and know that it can trust the connection.

 

Solution

You can use the browser to view the website's current certificate, so we can easily find out which chain we are assigned to. The function varies from browser to browser, but in most cases you will find a link to the certificate in the address bar, before the URL:

 

For our domain this is R10. We can then use the Let's Encrypt list to find the right key for the upload. In the example, we upload our certificate, the key for the certificate, and the key for R10. In most cases, the keys have the extension ".pem" and are therefore easy to recognize. It is important at this point to upload the key from the "Intermediate Certificate". and not the upload of the certificate itself. 

 

If we now test the SSL connection of the website again, we receive a positive message and our example from the beginning now works without errors.

 

Conclusion

In most cases, the errors are in the details and even if the website runs smoothly, it does not mean that SSL is 100% configured. At the latest when accessing via software, the chain of certificates is checked and a check is made to see whether the connection can be trusted.