algesten / acme-lib Goto Github PK

OCSP stapling support would be a great new feature: https://letsencrypt.org/docs/integration-guide/#implement-ocsp-stapling

It would be lovely to be able to access the existing keys and certificates on disk. Currently I just save my own copy with a known name, but that just feels ugly.

I just want to get raw strings out of it to store in a database

Hi!

As long as you consider your library somewhat production ready, you should add this library to the list of libraries on Let's Encrypt's website: here. There are directions on how to add the library to that list at the bottom of that page. I found your lib just poking around crates.io, but it would be helpful to have this posted on that list.

PS Thanks for the lib, I am going to try to work it into a library I have!

Hi there, I'm considering this lib to use in my project, how do you renew the cert does new_order renews the cert if its expired?
Thanks

I built a tool for creating letsencrypt certs, integrated with our DNS infrastructure. At this point, I could create cert and key for any service and then disseminate the files to the system/load balancer in question.

However, it would be great if the services could create CSRs and submit those to the internal cert-tool, so the private key never leaves the service system.

Can any estimation be made as to whether it would be possible and how much effort this might take? I am not familiar with ACME. Depending on the details, I might be able to contribute substantially to a solution.

Hi there! Thanks for creating and maintaining this.

Since this crate depends on openssl, it is not fully self-contained. I've already encoutered a bunch of problems because of either lacking or mismatching openssl versions.

I don't think openssl is needed. I suppose a crate like ring has most of the crypto capabilities that we need here. Perhaps rustls could also help?

Not sure if I can help here, but wanted to drop the request anyways!

Right now there's just HTTP and DNS challenges, it'd be great if ALPN challenges were also supported

The current ureq 1.5.5 dependency is pulling in an extra old version of rustls (0.19); since I noticed that you're also the author of ureq, is this an easy update?

On one of my partitions I get this:

thread 'dir::test::test_the_whole_hog' panicked at 'affine_coordinates_gfp: ErrorStack([Error { code: 268910693, library: "elliptic curve routines", function: "EC_POINT_get_affine_coordinates_GFp", reason: "incompatible objects", file: "ec_lib.c", line: 908 }])', src/libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
test dir::test::test_the_whole_hog

It happens when we try to get the public key from a saved account key.

        let mut ctx = openssl::bn::BigNumContext::new().expect("BigNumContext");
        let mut x = openssl::bn::BigNum::new().expect("BigNum");
        let mut y = openssl::bn::BigNum::new().expect("BigNum");
        a.private_key()
            .public_key()
            .affine_coordinates_gfp(&*EC_GROUP_P256, &mut x, &mut y, &mut ctx) // HERE
            .expect("affine_coordinates_gfp");

So in summary:

• Works when the key has been created using EcKey::generate(&*EC_GROUP_P256)
• Doesn't work when the key is read from EcKey::private_key_from_pem(pem)

Theory: The error is from a comparison that ensures the point belongs to the curve provided. We have double checked it is the same curve. It could be that the curve (group) is not persisted in the PEM and read back properly.

Please release commit 262628f as 0.3.2
I need to depend on that old version of ring, but need the Fix introduced by that commit to make my life easier.

Thanks,

#15 #16 and #17 all point to a similar story: The desire to have a persistence that is less controlled by acme-lib.

The current idea is that the user either uses the default persistence implementations or implements Persist, which is a simple key/value protocol. The question is what is lacking in this approach?

Hi,

First of all thanks for all the work on acme-lib, it's really nice to use 😉

We identified a potential issue when acme-lib did its upgrade to ureq v2, which came with the underlying update of base64.
We immediately saw a regression in a test with Let's Encrypt (using ACME protocol).
Apparently, the previous version of acme-lib was not using padding in base64url function, where false arg is whether you want to pad or not.

When receiving the response of Let's Encrypt server, we got the following decoding error, wrapped into an ApiProblem:

"urn:ietf:params:acme:error:malformed: Parse error reading JWS"

Following diff solved the issue.

diff --git a/src/util.rs b/src/util.rs
index f4490d9..26282c1 100644
--- a/src/util.rs
+++ b/src/util.rs
@@ -5,7 +5,7 @@ use crate::req::req_safe_read_body;
 use crate::Result;
 
 pub(crate) fn base64url<T: ?Sized + AsRef<[u8]>>(input: &T) -> String {
-    base64::prelude::BASE64_URL_SAFE.encode(input)
+    base64::prelude::BASE64_URL_SAFE_NO_PAD.encode(input)
 }
 
 pub(crate) fn read_json<T: DeserializeOwned>(res: ureq::Response) -> Result<T> {

I'm running into a case where if I pass a non-wildcard name into new_order as the primary name but include a wildcard name in the aliases, the cert is persisted under the wildcard name instead of the non-wildcard primary name. I suspect this is happening because:

Section 7.4 of the ACME spec states that:

Clients MUST NOT make any assumptions about the sort order of
"identifiers" or "authorizations" elements in the returned order
object.

This means that the primary_name that I pass into new_order might not actually be used to persist the cert here as the order of the domains could change:

The spec is a bit confusing because it also says the following in Section 7.1.3:

The elements of the "authorizations" and "identifiers" arrays are
immutable once set. The server MUST NOT change the contents of
either array after they are created. If a client observes a change
in the contents of either array, then it SHOULD consider the order
invalid.

I believe they just mean that entries can't be added/deleted though and that the ordering of entries can still change.

Lots of the links in the Readme are broken. Also the indentation of the function body in the example is wrong. Just in case you hadn't noticed!