Boulder: issuer cert in docker setup with wrong scheme

Created on 2 Dec 2017  路  6Comments  路  Source: letsencrypt/boulder

Just installed the latest boulder again cleanly. In my Apache test suite, I get the following:

  • account registry works
  • challenges work
  • certificate gets issued
  • obtained certificate reports issuer: CA Issuers - URI:http://boulder:4430/acme/issuer-cert

/etc/hosts has boulder as 127.0.0.1 and it is listening on 4430, but with https:, not http:

Anything I can tweak to fix that? Thanks!

areca kinquestion layeconfig

All 6 comments

Edit test/config/ca.json, look for issuer_urls, and change that. Do the same thing in test/config-next/ca.json for completeness, and send us a PR? Thanks!

BTW, any particular reason to pull from the AIA/CA Issuers extension rather than from the link relation made available through the API? If you always chase the AIA extensions, you will wind up over-including intermediates once we switch to our own (cross-signed) root.

Right now we are cross-signed at the intermediate level, and both the API and AIA chasing will get you a single intermediate. However, at some future date, we'll get cross-signed at the root. That'll mean we have a variant of our root certificate cross-signed by DST Root X3; that variant not be self-signed and will have an AIA extension pointing at DST Root X3. So a straightforward AIA chasing algorithm would include a copy of our cross-signed root, regardless of what the API says. However, we will configure our API to return a chain that still only goes one level deep, to our intermediate. That way, servers will serve a short chain (one intermediate), and all platforms that inherently trust our root will validate that chain. On platforms that do not inherently trust our root, but do support AIA chasing in the browser, our cross-signed root will be fetched, and the chain will be validated.

Hi @icing,

Thanks for the bug report.

obtained certificate reports issuer: CA Issuers - URI:http://boulder:4430/acme/issuer-cert
/etc/hosts has boulder as 127.0.0.1 and it is listening on 4430, but with https:, not http:

I believe you will want to change the test/config/ca.json config file (or test/config-next/ca.json) to set the correct issuer_urls value for the CFSSL signing profile. Unlike the header we can't make this protocol relative (AFAIK)

Alternatively, the Issuer field from the Link header relation should use the same protocol scheme as the ACME request.

Oops! I raced @jsha on my response. Apologies for the noise.

Guys, thanks for the help.

I though getting the issuer from the certificates themselves is the more safe and stable way. But now that I see @jsha explanation of cross signing, following directions might be better.

I see that the server gives an up relation on the issued cert resource. In the test server it stops there. When the chain is longer, will each URL have such a relation und if not, that is the last one to retrieve?

I see that the server gives an up relation on the issued cert resource. In the test server it stops there. When the chain is longer, will each URL have such a relation und if not, that is the last one to retrieve?

Yes, in theory, each URL should have a further "up" link, and when you see no more, you'll stop there. Right now this isn't implemented in Boulder because we don't plan to have chains longer than 1, but it's possible other Boulder-compatible servers might.

In ACMEv2, we've simplified this a lot by just having the server return a PEM certificate chain in one request, rather than making clients chase links.

Thanks guys, just implemented the "up" link following for the next mod_md release.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rolandshoemaker picture rolandshoemaker  路  5Comments

jsha picture jsha  路  3Comments

pauladams8 picture pauladams8  路  4Comments

pgporada picture pgporada  路  3Comments

Darkspirit picture Darkspirit  路  5Comments