So the question is
What is the difference between testing certificate (not a live one) from Let's Encrypt staging env and production env certificate? Is there a difference in the sense of security? What will happen if I use testing cert in production project
Every client will give a certificate error, because the staging CA isn't trusted. And that's the only real difference between the two--the production CA is trusted, while the staging CA isn't.
In addition to that, there are also differences regarding the overall system, for example higher rate limits, different validation strictness and so on.
In terms of security, the staging certificates are not audited, potentially less secured and relying on them for trust verification (i.e. adding them persistently to production trust stores) is unwisely.
I'm intrigued by the notion...
Please do explain more about exactly how you would use the staging cert.
[trying to imagine a use case for this]
Really? I thought (at least part of) the point of the staging environment was that it would validate in the same way as production, and thus be a valid test of whatever issuance mechanisms you were using.
New features are often tested in staging. This can lead to behaviour that is enabled in staging, but disabled in production. Sometimes features get stuck in staging and never* really make it to production.
*Never say never, eventually those may get enabled in production.
Current examples (not necessarily complete):
POST-as-GET is mandated in staging, but not in production
RFC 8657 (CAA extensions) are supported in staging, but not in production
looks like BR did updated CAA from RFC 6844 to RFC 8659(which was 6844-bis in draft) which was blocking to enable rfc 8657 in producion. can it activated in production now? @lestaff
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.