Can staging/fake-root private keys be publicly divulged?


#1

I’m working on a client and would like to include sample certificate pairs in the distribution for unit tests for automated tests.

I can use self-signed certificates, but it would be preferable to use ones that come from LE’s staging server. No big deal if this is not allowed.


#2

Pretty sure the answer would be no to providing private keys. In reality they are no different to self signed ones though ( and you can self certify in whatever name you like as an authority), they just won’t be recognised as valid, in the same way that the LE staging one’s aren’t.


#3

The private key (and certificate) from the staging server can be found in the GitHub repository for Boulder as far as I know. Dunno where exactly, but it should be somewhere :stuck_out_tongue:


#4

There are a bunch! I just had to search “-BEGIN CERTIFICATE-”

The client I’ve been working on has a SQL based admin tool for cloud deployments. There is some stuff that explores cert chains, so things line up better between offline and online tests if I use the ‘real’ fake CA.


#5

Until recently, the staging environment used the same “happy hacker fake CA” issuer as the dev environment, whose private key was available in the Boulder repo. We recently generated a separate set of certificates and keys for staging. Now the staging intermediate is “Fake LE Intermediate X1”. Keeping the private key for staging secret allows us to submit to the “testtube” CT log from staging.

However, I think that might not be what you’re asking. It sounds like you’re asking: If you generate a certificate from the staging environment, is it a violation of the Subscriber agreement to reveal its private key. The answer is no - you don’t need to agree to the subscriber agreement to use staging (though I should check the config there), so it’s fine to reveal private keys for the untrusted certificates you get from staging.

However, keep in mind that anyone with access to the private key can revoke a certificate, both on prod and on staging.


#6

Yes, that is my intent. I would prefer to ship a test suite that includes certificates signed by “Fake LE Intermediate X1” along with their corresponding private keys.

That would make tests a lot easier:

  1. Most tests are done offline with the fake cert and key.
  2. The few online tests that want to hit the Staging API can tie the shipped + testsuite-obtained certs together for confirmation. (that breaks when the staging cert changes, but i’m fine with that. this is all about trying to uncover all the various issues.)

I want to set this up for travis, and not being able to ship a stock cert would mean the test suite must first grab an API cert from fakeroot as part of a global setup then use that. that will really overcomplicate my time commitment for this side-project.


#7

If you already have to and you want to remove that, could you ensure that there’s a blank subscriber agreement, so client agreement can be tested?


#8

Yep, we’ll make sure the flow stays the same as prod.


#9

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