The topic of certificates is a confusing one. This text is the attempt to explain the why and how of certificate-based authentication and the difference between client certificates and server certificates. While Bob and Alice make an appearance in disguise, we try to keep the technical parts simple and only assume that the reader knows the general mechanism of asymmetric cryptography (using a key pair such that text encrypted with the one key can only be decrypted with the other).
This blog post tries to provide some background for a second text that talks about the specifics of connecting to SAP S/4HANA Cloud Public Edition using authentication with client certificates.
Why Certificate-Based Authentication?
With traditional basic authentication, credentials (username and password) must be known to both the client and the server for authentication. This means that the secret password must be securely distributed to the client and server in some way.
With certificate-based authentication (also called X.509 after a format for certificate files, or mTLS after a protocol implementing certificate-based authentication), the client only presents a certificate that is then verified by the server. In this asymmetric authentication, only the client keeps a secret, the server only uses public information to verify that the client is in possession of the secret. This means that no exchange of secrets is required beforehand and fewer parties need to keep secrets.
And this is just one of multiple advantages of certificates over passwords. Certificate-based authentication is a de-facto standard for system-to-system communication in security-aware organizations and a general best practice.
What is a Client Certificate?
In essence, a client certificate is a public key (in the sense of asymmetric cryptography) that is signed by a trusted certificate authority (CA) and for which the client holds the corresponding private key.
"Trusted" in this context means that the system we want to connect to believes that the signing CA has sufficiently verified our identity before signing the key.
As an example, the CAs that SAP S/4HANA Cloud Public Edition trusts are listed in SAP Note 2801396. Only client certificates with signatures by one of these CAs will be accepted by the system for authentication. In particular, self-signed certificates or certificates signed by company-internal CAs are not accepted.
And What is a Signature?
Cryptographic signatures are not restricted to certificates. They are a means for verifying the integrity and authenticity of messages in general.
In very broad terms, this is how a signature works: a message is sent through a hash algorithm to produce a unique (ok, "reasonably unique" for mathematicians) fixed-length string. That hash value is then encrypted with the private key of an asymmetric key pair. The resulting ciphertext is the signature of the original message.
And how does the signature guarantee the integrity of the message? The signature is sent together with the message, so the receiver of the message can decrypt the signature using the public key of the asymmetric key pair and compare it to the hash of the message (the hash function is public knowledge). If hash value and decrypted signature are the same, the message is intact. If they don't agree, either the message or the signature was changed. In either case, the message can't be trusted to come from the owner of the public/private key pair. And because only the holder of the private key can create the signature, a valid signature also guarantees authenticity of the message.
In the certificate case, our public key is the message: The CA takes our public key, appends some metadata (the subject, expiry date, issuer identification...) and hashes it. Then the hash is encrypted with the CA's private key. The result is our certificate: a public key plus metadata plus signature by the CA. By slight abuse of notation, we say that the CA certificate signs our certificate, while it's really the private key belonging to the CA certificate that does the signing.
Validating the signature means that the receiver of our certificate calculates the hash of the public key (including metadata) and decrypts the signature using the public key of the CA (the CA's certificate). If the decrypted signature and the hash are the same, our certificate is valid and has not been tampered with.
How Does That Authenticate a Client?
To the server, authenticating clients are just users. When a client authenticates, that means that the corresponding user logs on to the system.
To be able to identify and authenticate a user, the user is assigned a unique certificate – just as the user would have a unique name/password pair for basic authentication. The certificate is not a secret, though, it's just a public key. We can interpret this mapping as "anybody who has the private key for this public key will be treated as this user" (just as anybody knowing the right name/password combination would in basic authentication).
The certificate-based authentication flow can be thought of like this:
- the client hands over its client certificate (which contains the client's public key) to the server
- the server verifies that the certificate is signed by a trusted CA (i.e., the CA certificate is in the server's list of trusted certificates)
- the server encrypts a random message with the public key from the client certificate and sends it back to the client
- the client decrypts the encrypted message (using the private key) and sends the plaintext back. Now the server knows that the client has the private key of the certificate
- the server looks up which user has the certificate assigned – that user is successfully authenticated
While that's not exactly what happens, it hopefully conveys the general idea.
A few side remarks:
- In the authentication flow outlined above, no secrets are exchanged. This is a major security benefit. The idea of the challenge-response protocol is that the server presents the client with a task that can only be solved if the client has the private key. If the client solves the task, the server is confident that the client must have the key – without being shown the key itself (this is sometimes called a zero-knowledge proof).
It might sound like magic, but it's really just very clever mathematics. - The statement "the user is assigned a unique certificate" is not completely correct. In fact, only the issuer and subject of the certificate are mapped to the user, not the entire public key.
This is made possible by the trust relationship between server and CA: The server trusts that the CA checked that the owner of the private key is sufficiently identified in the certificate's metadata already. So, the server trusts the metadata in the certificate rather than demanding an exact public key match.
This has a big advantage: when the client certificate expires, we can exchange it for a new one with the same subject and issuer without having to re-upload it to the system. - As already mentioned in the introduction, this setup does not involve exchange of secrets. No password has to be given to the server administrator to configure the connection. And certificate rotation is a one-sided process that does not require simultaneous changes on client and server side (as password rotation does).
- If the server is hacked, no secret credentials can be stolen. This means that the "no password reuse!" imperative does not apply to certificates. We can use our client certificate to authenticate to multiple systems (and we actually do in SSO setups).
Client Certificate, Server Certificate – What's the Difference?
Technically, client certificates and server certificates are the same thing. The difference is in the usage of the certificate. Let's have a look at what happens when a client calls a server (in the TLS handshake that also happens when a browser calls a website):
- the client asks the server to establish a connection
- the server hands over its public key (the server certificate) to the client
- the client verifies that the certificate is signed by a CA it trusts
- the client verifies that the server is in possession of the private key of the certificate
- the connection is established
Again, that's not exactly how the TLS handshake works, but it's close enough as a mental model.
And yes, that's the same thing that happens as above (section "How Does That Authenticate a Client"), with the roles of client and server interchanged. In the TLS handshake, the server authenticates against the client. Note that at the end of this flow, the client has assurance as to the identity of the server, but the server knows nothing about the client's identity.
But where does the trust in the CA come from? Clients maintain a list of trusted CAs. And often client software is shipped with a pre-configured list. Operating systems also maintain a list of trusted certificates that is pre-populated by the vendor.
And where's the user-certificate mapping? It's implicit: the server's "username" is the host name. The server certificate's subject attribute says "this certificate is issued for example.com". So, if the client calls the server example.com and is shown a valid certificate issued for example.com by a trustworthy CA (and the server proved that it has the private key), the client can be sure it's really talking to the right server and not some man-in-the-middle. In browsers, successful verification is shown by a padlock icon next to the URL.
How do the Two Come Together?
When we log on to the system, the client first authenticates the server to establish a connection: The client verifies that it's talking to the real server by checking the server certificate (server's name is in the "Common Name" or "Subject Alternative Names" of the certificate, the signing CA is trusted, certificate has not expired, and the server has the certificate's private key).
In a second step, the server might (or might not as in the case of public websites) authenticate the client/user.
The server's authentication against the client is always using certificates, while clients/users might authenticate against the server using different methods (certificate, basic authentication, token...).
Fun fact: if server1 does a technical call to server2, then server1 presents a client certificate to server2 (because server1 is the caller and hence assumes the client role in this communication). And server2 presents a server certificate to server1. The notation is a bit of a mess…
Aside: Root Keys, PKIs, Validity
Root Keys and the Chain of Trust
As seen above, a valid certificate is one that is signed by a trusted CA. More precisely, it's signed by the certificate of a CA (a signing certificate). That signing certificate in turn is signed by another of the CA's certificates, the root certificate.
Browsers and other clients often trust the CA's root certificate rather than the individual signing certificates. This makes certificate validation a multi-step process but reduces the number of trusted certificates.
Public Key Infrastructure
This setup of root certificates, signing certificates and trusted issuers is part of the Public Key Infrastructure (PKI). The fundamental assumption of this infrastructure is, that there are a few (quite a few, in fact) trustworthy institutions that will dutifully do the identification of servers and individuals so that everybody else can trust the certificates issued as a result of this identification. These trusted institutions are the CAs and their associated registration authorities (which verify certificate applicants – potentially even by inspecting physical documents). All this is pretty similar to the infrastructure for passports in the real world.
Local PKIs/CAs
Anybody can create a CA, of course – the question is just "who will trust it?". It is not uncommon for companies to maintain a company-internal CA that is only trusted by the company's own servers/clients/users. The CA will issue server certificates for internal applications, client certificates for system-to-system communication, and SSO certificates for users (also a kind of client certificate). All this works if the company-CA's root certificate is trusted by all involved parties (it might be provisioned to all computers with the base-image, via a device management system, or by manual import into the operating system's certificate trust list). But it does not work for communication to the outside (e.g., towards 3rd party SaaS solutions) because the outside party does not trust the company-internal CA.
Certificate Validity and Rotation
An important aspect of certificates is their validity. Certificates are only valid for a certain period: server certificates often expire after a year, root certificates can live for decades, signing certificates for a few years. Validity is part of the certificate metadata itself and cannot be changed, so the certificate has to be renewed ("rotated") before expiration.
Certificates expire silently, but the effects can be rather spectacular. If a signing certificate expires, all certificates that were ever signed by that signing certificate become invalid. Expired certificates break TLS connections and client authentication – systems don't talk to each other anymore. A forgotten certificate can turn into a very expensive and difficult exercise.
Up Next: How to Actually Use Client Certificates in SAP S/4HANA Cloud Public Edition
Now that we got some of the basics covered, it's time to look at an example.
In a follow-up blog post, we will see how to create a client certificate and how to use it for authenticating against an SAP S/4HANA Cloud Public Edition system.
The scenario will be like that: we configure SAP S/4HANA Cloud Public Edition to expose an API (an "inbound" communication arrangement) that we will call with a technical communication user. And that user authenticates using a client certificate.
But all this is the topic of the next blog post.
- SAP Managed Tags:
