Reading time: 7 min read
FAQ: Sitecore 9, xConnect, Client Certificates And SSL Certificates
xConnecting The Dots On Certificates
Start typing to search...
If we're installing XP0 on a dev machine, maybe not so much. But if you're deploying a Sitecore 9 & xConnect in a scaled environment on IaaS or PaaS you can be forced to learn in a hurry.
There is information out there on SSL certificates & client certificates but when you read it it's difficult to map into a the proper context for Sitecore 9. At least we've found it difficult!
So instead interpreting academic deliberations and Stack Overflow posts about certificates that almost make sense, I'm attempting to answer questions about certificates specifically as they relate Sitecore 9 & xConnect. The FAQ is grouped loosely into:
They are both certificates but the are for very different purposes. It can be confusing because generally we use SSL and certificate interchangeably because an SSL certificate is the only type we'd use.
SSL Server certificates (think GoDaddy) are used to provide a secure transport layer for transmitting information.
Client certificate play no role in the encryption of data and are used to authentication and identification purposes.
TLS (Transport Layer Security) is the successor to SSL (Secure Sockets Layer) protocol that provides secure cryptographic communication between computers. Both are used by the HTTPS protocol. For the purpose of this article however SSL & TLS will both be referred to as SSL (old school)
It's a certificate used as an intermediary (think - like a proxy) in a change of trust between a certificate and a certificate authority.
Some certificate authorities will no sign certificates directly. Instead, they'll create certificates from an intermediate certificate and give you the intermediate certificate to install in your trusted root store.
The certificate authority trusts the intermediate, you trust the intermediate, and your certificate inherits "trust" from the intermediate. Does that make sense? This also allows an intermediate certificate to be untrusted by a certificate authority, thus invalidating every certificate that relied on it.
xConnect is the server. Sitecore (CM or CD) is the client.
This means Sitecore's SSL Server certificate does not factor into xConnect's communication. Think of Sitecore as an application running your computer that makes a request over HTTPS to xConnect.
Sitecore will include a client certificate with these requests to xConnect to authenticate itself.
Sitecore is the client and xConnect is the server. This means that Sitecore is making the request to xConnect.
This also means that because xConnect is the server, it's required to have an SSL Server certificate added for secure communication.
The client certificate is authenticated by the certificates thumbprint. You will find the expected thumbprint within the xConnect AppSettings.config files as so:
<add key="validateCertificateThumbprint" value="124F8F3DBB3A7E32F164CE2699850D7D90CD17DA">
In XP1 environments, the following roles require client certificates:
xConnect Collect xConnect RefData xConnect Search
In XP0 environments, the above roles are combined into a single xConnect server.
No. Your client certificate does not have to be related to your SSL certificate. They are two 2 certificates, used for different things.
An HTTPS request uses a trusted SSL certificate to encrypt the data. And a client certificate, which can be completely unrelated, is included in the HTTPS request and used for application level authentication within xConnect
CD should have HTTPS certificate. xConnect must have an have HTTPS certificate. CD & CM must use the same client certificate to authenticate with xConnect
It's used as cryptographically secure method of authenticating between Sitecore & xConnect. It's also considered more robust and secure than typical username and password authentication.
Client certificates are used for authentication. They're like a secret password embedded in a request. For example, the server receiving the request can be configured to reject any request that does not include a specific client certificate.
When implemented, they're consider a strong indicator the request for information comes from a trusted source.
You cannot purchase a client certificate.
However, when you purchased your SSL Server certificate you many have been provided with an Intermediate Certificate. This can be used to create a client certificate.
That said, it is extremely unlikely that a commercial certificate authority would allow users to sign certificates with an intermediate certificate. So again, no.
Client certificates can only be added as part of an HTTPS request. And of course HTTPS request requires a valid SSL certificate.
So first we need HTTPS, then we can really lock down the connection by using a client certificate.
I would say no, not even in production.
While it's "recommended" to use a trusted client certificate in production by Sitecore themselves, I think it's unnecessary. It creates a virtually insurmountable hurdle in many environments.
It's only used as a mechanism of authentication between machines. At the application level, xConnect itself does not even evaluate all aspects of the certificate for validity - it only matches the thumbprint.
It can very complicated for organizations to generated trusted client certificates, particularly when in environments such as Azure the trusted roots cannot be added to.
You do not. You simply need to ensure that the AppSettings.config files allows for invalid client certificates by having the following set to true:
<add key="AllowInvalidClientCertificates" value="True">
When deploying on Azure, you can not add Trusted Root certificates.
On a Windows Server you have full control of the certificate store and can make self-signed or internal corporate certificates trusted. So if a certificate was signed by "Fishtank Consulting" I could register Fishtank Consulting as a Certificate Authority by adding it as a Trusted Root on Windows Server - making the certificate valid.
On Azure, I could never make this certificate trusted as I cannot modify the Trusted Root store.
If I was betting man. I would say you cannot. The problem is that you can't alter the trusted root certificates in Azure. And no Certificate Authority (i.e. trusted root certificate) is going to give you an intermediate certificate that you can use to sign your own certificates with - client or otherwise. https://getfishtank.ca/sitecore/shell/Applications/Content%20Editor.aspx?sc_bw=1&sc_lang=en#
Minimal. Client certificates do not have to be trusted by third-parties to work effectively. They only need to be trusted by xConnect to work, and xConnect role only checks if the client certificate thumbprint matches the expected value set in it's AppSettings.config
There is a lot information I'm expecting to add to this still. But if you have any immediate questions please reach out to me on Twitter at @dancruickshank and I'll do my best to answer your question and add it this page. Thanks!