Comments (7)
Thanks again!
I'm going to keep an eye on progress, and try and get some testing against v2 API as soon as the golang library supports it. Exactly how I model this in cert-manager (to allow users to decide between different versions) I'm not sure, but I've had quite a lot of requests for wildcard support in the past so I'd like to support it soon after January!
Looks like I'm back to running a full boulder for e2e tests! Thanks 😄
from pebble.
Looks like I'm back to running a full boulder for e2e tests! Thanks 😄
Happy to help! If you find something particularly painful about using Boulder for integration tests please let us know. Within reason we'd be happy to try and make it easier.
from pebble.
Ah - I see from discussion here and looking through this projects history that this is meant to support the ACME v2 protocol only, so looks like I can't use pebble just yet in my tests.
I assume LE will start serving acme-v2.api...
once it's ready to roll out, and then support both versions of the protocol for a period of time? If so, cool 👍 I'll just need to punt this task to a later date when everything supports v2!
from pebble.
From what I can tell, Pebble implements acme-08 (the latest draft of the spec), however boulder seems to be using some older implementation that has different field names. Is there some way I can discovery the version in use?
You got it. Pebble is meant to be as close to the current draft as possible. Unfortunately since Boulder evolved alongside ACME there isn't a specific draft version that it matches. The best way to understand Boulder's implementation of ACME is to read draft-07 next to the list of divergences. It's admittedly awkward
:-(
I'm using golang.org/x/crypto/acme as my ACME library, which appears to implement a pre-08 version of the spec (as it does not recognise new-account, new-nonce or new-order)
Yup, almost every existing ACME client implements "V1" (the Boulder ACME that isn't an exact draft version). I think that's a side-effect of our popularity and the draft status of the RFC 😊
Beyond the directory endpoint URL differences Pebble/V2 change the certificate issuance flow pretty substantial and also rework the JWS validation for most endpoints
I assume LE will start serving acme-v2.api... once it's ready to roll out, and then support both versions of the protocol for a period of time? If so, cool 👍 I'll just need to punt this task to a later date when everything supports v2!
We're targeting having a staging environment for V2 available in December. Both it & the eventual production endpoint will be available via a separate API URL. We have no intention of deprecating/removing the existing V1 API anytime soon (there's way too many clients using it!).
You should be very safe punting on V2 unless you or your users are especially interested in having Wildcard support ASAP. That will only be available via the V2 API in January.
Hope that helps clarify! I'm going to close this issue since we don't intend to add V1 support to Pebble at the current time.
from pebble.
It's been working well for me so far - I've used a simple git clone
and docker-compose up
up until now.
We're moving all of our e2e testing into Kubernetes however, so will be converting this compose definition into a Kubernetes deployment and running boulder within k8s itself.
The one thing I've not found, is any official images pushed to any public registries. Am I right in thinking that you just don't publish images and instead expect users to build their own? 👍 if so!
from pebble.
so will be converting this compose definition into a Kubernetes deployment and running boulder within k8s itself.
Neat!
The one thing I've not found, is any official images pushed to any public registries. Am I right in thinking that you just don't publish images and instead expect users to build their own? 👍 if so!
Yup, that's the case today. We have an open issue to publish images (letsencrypt/boulder#2865) but it isn't on anyone's plate. I don't think there's any philosophical opposition, just a matter of time and TODO wrangling.
from pebble.
The one thing I've not found, is any official images pushed to any public registries. Am I right in thinking that you just don't publish images and instead expect users to build their own?
That's mostly correct. We do build a boulder-tools image that has all the precursor stuff for boulder, then that gets pulled down in local testing and on Travis, and the actual Boulder image gets built on top of that.
Note that the resulting built Boulder image is way big, because it includes all the tools. We've been meaning to publish an image that's just "Boulder, as built." But it's a little complicated; for instance, right now our Boulder image entrypoint configures the HSM (in another container) and runs the database migrations if needed. Both of those require files that are in the source distro. Not an overwhelming obstacle, just a little annoyance. Long story short: If you'd like to contribute the code to auto-publish Boulder images, we'd be open to that!
from pebble.
Related Issues (20)
- Golang, apk and zlib versions are outdated HOT 2
- 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
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.