boulder icon indicating copy to clipboard operation
boulder copied to clipboard

exposing locally generated roots for integration tests

Open icing opened this issue 5 years ago • 10 comments
trafficstars

After updating to current boulder, my ocsp stapling tests fail. Reason being that the openssl client fails with Verification error: unable to get local issuer certificate.

I am giving the call -CAfile $BOULDER/test/test-root.pemand that worked until the boulder update. (I had not updated for some time, so the change might have been done months ago in your timeline.)

I assume the pem has moved somewhere else?

icing avatar Jun 19 '20 07:06 icing

I think #4832 changed things around so that the root and intermediates are generated at runtime using the new ceremony tool.

PKI.md got updated as well:

The private keys are stored in SoftHSM, and the public keys and certificates are written out to /tmp

Doesn't look like they're exported out of the container by default when using docker-compose.

alexzorin avatar Jun 19 '20 07:06 alexzorin

@alexzorin has got it exactly right, as usual. :-) We now generate a fresh hierarchy with each run. Sorry for the breakage! We don't currently export the certs, but I am open to ideas on how to do it for integration tests that incorporate Boulder.

jsha avatar Jun 22 '20 23:06 jsha

@jsha not sure I have a bright idea here. I added to my test suite code that copies docker:/tmp/*.pem into a local ca.pem and use that. The older path was reverse engineer also, so I cannot really complain. ;)

I guess, offering a ca.pem resource from some web server would work for an "official" test api endpoint. Maybe even for the live servers it wouldn't hurt?

icing avatar Jun 24 '20 13:06 icing

Coming back to this, I need an "official" point to get the root certificates for my test suite. I am prepared to do a docker cat from somewhere.

After hacking the location between different master revisions, I am currently unable to see any recent .pem in the boulder file system. Maybe its only in memory/database now?

icing avatar Dec 09 '20 12:12 icing

The generated roots should still be in /tmp/*.pem. The call path is test/startservers.py:setupHierarchy -> test/cert-ceremonies/generate.go, which in turn loads config files from test/cert-ceremonies/*.yaml. Those yamls configure the output paths. For instance, https://github.com/letsencrypt/boulder/blob/main/test/cert-ceremonies/intermediate-ceremony-rsa.yaml#L9 outputs to /tmp/root-cert-rsa.pem. Note that there are some small shenanigans in generate.go that rewrite some output paths, but not for the root, and everything still gets put in /tmp/.

jsha avatar Dec 09 '20 16:12 jsha

Thanks jacob. For some reasons, the files were not there. I removed all docker things and updated everything and now it's running fine again.

Should have done that right away. Sorry for the noise.

icing avatar Dec 09 '20 22:12 icing

No problem. Always nice hearing from you. :-)

jsha avatar Dec 09 '20 22:12 jsha

@aarongable is there any appetite for serving the root CA cert from the docker container at runtime at a stable path? (or is this issue closed because this is done already?)

acharis-do avatar Apr 18 '22 15:04 acharis-do

Yes, I think there's some appetite for that. From the discussion about, @icing was able to get it out by docker cating (presumably docker exec boulder cat /path/to/file) the files from /tmp/root-cert-rsa.pem (and now /tmp/root-cert-ecdsa.pem). Does that work for you? We could just commit to those paths being medium-term stable, since they haven't changed in a while and we don't expect them to change soon.

jsha avatar Apr 18 '22 17:04 jsha

i think they're in /hierarchy now, rather than /tmp if i'm reading things correctly. i was hoping one of the services started by startservers would expose them at an endpoint.

acharis-do avatar Apr 18 '22 17:04 acharis-do