Comments (6)
Yes, something like /root
sounds like a good idea for Pebble. I should be able to give this a shot the next days.
I definitely don't want the ACME spec delayed because of this :) But it's definitely something which should be solved eventually. I'll start a discussion at some point.
from pebble.
For me, this is a general issue with ACME (v2). The root certificate is sometimes needed; for ELB/AWS (as @jderusse pointed out here), or for nginx OCSP verification enabled with ssl_trusted_certificate set.
Of course, an ACME client can in general extract the root certificate from the system's (or it's own) CA bundle. But that doesn't always work, like for Pebble (where the root certificate seems to be only available in Pebble's memory), or maybe for some half-private CA, were the system requesting the certificate does not have the CA's root in its own CA bundle.
Currently, the only thing that works (for regular ACME CAs, i.e. Let's Encrypt production and staging) seems to make the root certificate configurable, forcing the end-user to provide it next to the CA's directory URL. That's pretty annoying, in particular if a CA ever needs to switch to another root, or different certificates (with different intermediates) require different roots.
The ACME specs (Section 7.4.2) do not mention the root certificate; for me, it is not clear whether I would expect it to be included or not (I guess currently clients assume it is not included, because neither Pebble nor Boulder include it), and how to obtain it if it is not included in the certificate chain.
from pebble.
Hi @felixfontein,
You raise a good point about requiring the root certificate to perform an end-to-end validation of the issued certificates.
It would be really nice to be able to get the root certificate from somewhere (i.e. Pebble writes it to disk, or provides an endpoint where it can be read with a GET).
I think providing it by GET would make sense. I think writing it to disk would be more complicated and we already know ACME clients are set up to GET resources from the ACME API endpoint.
Maybe something as simple as a /root
handler that returns the CA certificate?
For the larger question of how ACME should handle this case I think a new thread on the ACME WG mailing list is the best bet. Given that the draft is in last call and this is a fairly minor corner case I don't think there will be considerable appetite for fixing it in the current draft but I think starting the discussion is a good idea.
from pebble.
Wouldn't the directory/meta structure be a good place for it? The root certificate could be added there as binary, or as an URL where it is available for download.
from pebble.
@shred I think it is a very bad idea for a real CA (for Pebble it can be fine), as different certificates could use a different root. If you embed a single root in directory/meta, it can be pretty unclear for which certificates this root is valid and for which it isn't (without going through the chain). So this should be something provided per order (or per finalization, same as the intermediate certificate).
Also, I don't think it is a good idea for Pebble, as some client devs might get the idea that this is something they can expect from other ACME implementations as well. Though they'll probably notice pretty quickly that it doesn't work like that :-)
from pebble.
I think for now keeping it outside the meta
as a Pebble specific URL documented in the README is fine.
from pebble.
Related Issues (20)
- Allow to force auth challenge HOT 1
- Implement the "dns-account-01" Challenge in Pebble HOT 9
- Full http logging HOT 1
- fix appveyor CI
- Support must-staple extension HOT 1
- Fix `golangci-lint` HOT 3
- Regression time limit exceeded / TimeoutError HOT 5
- Request for a new release HOT 6
- v2.5.0 docker push failed HOT 9
- ci: AppVeyor is broken HOT 1
- Remove DockerHub images of pebble and pebble-challtestsrv HOT 4
- Cannot set DNS server in Docker image HOT 10
- Docker: Use hostname instead of IP addresses HOT 7
- New Certificates aren't getting Ready HOT 2
- EAB with pebble 2.5.x HOT 12
- Pebble fails to start with externalAccountBinding test config
- The request specified an account that does not exist, [certbot and pebble] HOT 2
- The key authorization file from the server did not match this challenge HOT 1
- Pebble seems to reuse challenges object for different orders HOT 2
- Support profile selection HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pebble.