Support staging vs production as a run-time option

[kylepl]

Support staging vs production as a run-time option

[jmccl]

That’s a reasonable request, but let me explain why I didn’t do that originally.

Normally you want to deploy the same code everywhere and have configuration control which endpoints the code is talking to. So in a test environment, you connect to the test login vip, but in a production environment you’d connect to the production login vip (for example.)

I don’t think this is true for this code. I think - unless you’re a developer making changes to the library itself - you always want to be connecting to the production Let’s Encrypt servers and never the staging servers, even in a test environment. This is because the library simply doesn’t work unless publicly facing DNS allows a Let’s Encrypt system (production or staging) to connect to a host on the internet. There’s no way for Let’s Encrypt (production or staging) to complete certificate issuance unless this is true. And if it’s true, there’s no reason not to simply connect to the production Let’s Encrypt instances.

Now, there is one reason I can think of why my argument above might be in error: the staging rate limits are different than the production rate limits and a test environment might break if pointed at production Let’s Encrypt. That strikes me as pretty unlikely, but let me know if that’s your concern.

On the other hand, there is an advantage to not having this be controlled by configuration; namely it’s much harder to screw up.

Let me know your thoughts. At the moment I think it's not a great idea, but I’m not totally closed minded although I’d want an explanation of a reasonable use case.

[kylepl]

I appreciate the thoughtful reply.

A few thoughts:

• I think it isn't just for developer for acme-lw, but also for integrators (which is what I would classify myself), that you would want the staging environment.
• The rate limiting is main concern of the two concerns - since I'm experimenting with getting this hooked up to my frontend / storage, I want to iterate and try many times - without hitting the prod rate limit.
• The other piece is that since I'm using staging, I'm able to test the whole flow without having to have amazing operation security for my private keys - since the certificates do not have a chain of trust to a root CA. To be precise, if my secret key was discovered by someone, they won't have any root-CA verified certs to go with it. I'm not certain how much this matters, but it seems like a low-cost benefit.

And to be honest, I'm new to this space, so I may misunderstand something. :)

[jmccl]

That last point hadn't occurred to be and I agree it's a legitimate concern. I'm tied up right now but I'll make a change 'shortly'. (Probably before the weekend?)

[jmccl]

I looked at your initial implementation suggestion. Couldn't the init call take the environment? Would anything need to switch back and forth between environments on a per AcmeClient basis?

[kylepl]

Having init take the choice sounds good to me.

No particular rush on my side, but will enjoy the feature when it lands. :)

[jmccl]

Change checked in.

[kylepl]

Thanks for the fast help! Switched to using it.