Storing of issued cert/keys demo setup

Hi,

I have a question regarding the Subcribers Agreement - hope this category is appropiate.

We have a demo setup for an application that can be bootstrapped completely by ansible from a git checkout by users who want to testdrive the whole stack. The whole setup is a private cloud environment completely self-contained with private networking. In order to have valid TLS connections within this setup we want to store a valid wildcard LE certificate (and key) alongside with it (which we would automatically rotate every 90 days).

The Subscribers Agreement states:

You warrant to ISRG and the public-at-large that You have taken, and You agree that at all times You will take, all appropriate, reasonable, and necessary steps to maintain control of, secure, properly protect and keep secret and confidential the Private Key corresponding to the Public Key in Your Certificate (and any associated activation data or device, e.g. password or token).

From my understanding, since this is a demo setup that can be bootstrapped automatically that works with private networking only, the handling of certificate/key is reasonable and appropiate.

thanks

felix

2 Likes

So if I understand this correctly, all instances use the same wildcard cert and arbitrary users can get an instance and thus have access to that wildcard cert?

If this is correct, even if your networking is somehow isolated, users can still use the wildcard to impersonate others (either on the same network, or also on other networks that use the same hostname - certificates are not bound to networks, but to domain names).

From my reading of the SA, I think this is not allowed. To me the entire paragraph reads like "you must not share the private key with others". This is only my personal view though and is not legal advice :wink:.

7 Likes

I tend to agree.
Even if the users don't share that information, you are.

5 Likes

If the consumers have any access whatsoever to a shared key/certificate, which means access to that git or enough privs to read them on the machines, then it's definitely a violation of the TOS and an overall security risk.

I think it would be easiest to install the key/cert on a gateway and terminate ssl there, then just have app expect http traffic. You could also rely on an untrusted CA you control and have your systems trust that.

3 Likes

So if I understand this correctly, all instances use the same wildcard cert and arbitrary users can get an instance and thus have access to that wildcard cert?

The environment can be cloned from git and once bootstrapped will over a set of containers that run in a private network on a local machine.
Yes, the certificates are bound to the domainname, so in order for this to become a problem someone who wants to impersonate needs to run a dns server that sends spoofed replies.
However, thanks to your reply it actually highlights the risk vector here - even though the whole domain solemnly exists for the demo environment an impersonation could be done. Thanks - that helped!

7 Likes

If this is (or can be) run completely offline...
Why do you need a real trusted cert (for testing) ?

4 Likes

Why do you need a real trusted cert (for testing) ?

very valid question :wink:
Because browsers nowadays (which is good) make it fairly hard to access sites with self-signed certs.

1 Like

Understood, but "demo/testing" is expected to be "out-of-the-norm" and should NOT break their confidence when using a temp/self-signed cert.

2 Likes

Are all users "local"? I.e., within the same company and network? If so, it's probably way better to use your own private CA instead of relying on Let's Encrypt.

See also:

4 Likes

Not likely.

2 Likes

Again, this can be avoided by terminating SSL at the gateway into the network or on load balancers. The applications can speak to one another using certs that are either self-signed or from a (publicly untrusted) corporate CA that is trusted by the machines.

3 Likes

@Nummer378 and everyone else here on the thread is right. :grin:

According to our Subscriber Agreement, you're obligated to:

take, all appropriate, reasonable, and necessary steps to maintain control
of, secure, properly protect and keep secret and confidential the Private Key corresponding
to the Public Key in Your Certificate (and any associated activation data or device, e.g.
password or token)

And distributing it with your application would not qualify under that.

Also, anyone who can get access to your private key has the ability to revoke it via the ACME API.

Thanks for asking! Good luck with your demo setup. I hope you found the guidance you need here, and if not feel free to follow up.

8 Likes

Also, anyone who can get access to your private key has the ability to revoke it via the ACME API.

Thanks! I was not aware of that and that is another very good point.

Also thanks for re-confirming regarding the Subscribers Agreement. For this was very helpful as we already had looked at the 'own CA' route beforehand (since we also had the impression that it would not comply with the subscribers agreement - nevertheless, I wanted to reach out and actually reconfirm that).
With the point about the revokation it actually does not make any sense.

Also thanks to @Nummer378 @rg305 (and the others - but discourse only allows me to mention two people as a newuser :wink: for the feedback and assistance!

5 Likes

By the way, another common approach - even better than "own CA" for your use case - is to have your demo setup script generate a local CA for the user. For instance, mkcert is very good at generating local CAs and doing the necessary things to get them in the local trust store.

The problem with "own CA" for your use case is that you don't actually want your demo users to install your CA, because that might put them at risk if you leak the keys for your CA. Instead, you want them to install some CA that only they control.

7 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.