Certificate Pinning

Hi,

Thank you for raising the idea of adding certificate pinning. Security between Devolutions Server (DVLS) and Devolutions Gateway is central to many of our MSP customers, so we want to make sure we understand your environment and threat model before we size the effort.

How it works today:
During the TLS handshake, the Gateway presents its server certificate.
DVLS validates that

• the certificate chains to a CA in its trust store,
• the certificate (and every issuer in the chain) is in‑date and not revoked, and
• the certificate’s Subject Alternative Name matches the hostname DVLS connected to.

If all checks pass, the tunnel is established.
(If any of those assumptions do not match your deployment, please let me know.)

What pinning would change:
Pinning would allow DVLS to remember a specific certificate / public key or hash and refuse connections if the Gateway ever presents anything different, even one that is otherwise valid and signed by a trusted CA. This reduces the residual risks of internal CA misuse, DNS poisoning, or a future CA compromise.

To help us prioritise could you share a bit more?

1. Are your Gateways using certificates from a public CA or from a private/internal CA that you operate?
2. How frequently do you need to rotate those certificates?
3. Which scenario worries you most (e.g., insider issuing a rogue cert, DNS/host‑file tampering inside a client network, external CA compromise)?
4. Would pinning a public‑key hash (allows routine certificate renewals) satisfy the requirement, or do you need to pin to a specific leaf certificate?

Once I have this information I can log the request with clear requirements and update you on feasibility and timelines. In the meantime, if you have any supporting documentation or examples of how you handle pinning in other products, that would be helpful.

Thanks again for helping us harden the platform.

Best regards,

Hello Benoit,

thanks for your swift response.

1. Are your Gateways using certificates from a public CA or from a private/internal CA that you operate?
   1. They will be using certs from an internal ca
2. How frequently do you need to rotate those certificates?
   1. As these will be webserver certificates, and in prep to standard practices they will be rotatet every 47 days (https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days)
3. Which scenario worries you most (e.g., insider issuing a rogue cert, DNS/host‑file tampering inside a client network, external CA compromise)?
   1. In principle all of these, in particular DNS poisoning and host file tampering
4. Would pinning a public‑key hash (allows routine certificate renewals) satisfy the requirement, or do you need to pin to a specific leaf certificate?
   1. I forwarded this question to our security team and will submit the answer later

Thanks in advance

Hello again,

Thank you for the extra details, and kudos for choosing a 47‑day rotation window, that is a very strong security posture.

However, let me warn you about the operational impact of pinning with rapid rotation.
This is in fact closely related to the last question you forwarded to your security team.
If pinning the leaf certificate itself, each renewal would require two perfectly‑coordinated steps for every Gateway you manage:

1. Install the new certificate on the Gateway.
2. Push the updated pin to DVLS before the next connection attempt.

I fear that in an MSP scenario with dozens (or hundreds) of Gateways this can become error‑prone, time consuming and risks brief service interruptions whenever the two steps drift out of sync.

Most likely, your security team already understands the trade-offs better than myself, but let me dig a little bit the various options that could help reducing your burden, including the public-key hash option I mentioned earlier.

Pin the public‑key hash:
No update needed if you re‑issue renewals from the same key pair.
However, this requires you to keep the key pair stable throughout its life; renewing with a new key means updating the pin.
You are still protected against DNS poisoning, and rogue certs using a new key.

Pin your internal CA / issuing intermediate:
Certificates can renew freely; no pin updates.
However, an insider with access to the CA could still issue a rogue cert.
You are still protected against external CA compromise, and external DNS poisoning.

Automated pin‑update API (we add this as part of the pinning feature):
Details need to be thought through and designed, but it could let you rotate keys and pins automatically from your orchestration pipeline.
You get strictest pinning, but this adds implementation effort on our side and will take longer to deliver.

Maybe you could communicate this to your security team, and let me know which of these (or another) model aligns with your policy.

In an ideal world, we should provide you with all these options so you get the power of choosing what is appropriate, but I fear this increases the scope of the feature quite much.

Best regards,

Hi again,

thanks for this well thought response. I will provide feedback as soon as possible