I like that idea. Their non-async client works fine so the router and such handle that. It is only the async client failing so something like this looks more likely
3 Likes
This is a residential Orbi 850 router, not using the Wifi here, hardwired to the router.
Also this is IPV6 so the router should be doing nothing but forwarding the packets....
No NAT or other manipulation....
OK, but it is still very likely doing stateful inspection firewalling.
2 Likes
Ok when an authorization challenge goes to invalid...
Can I retry it or do I have to generate a brand new order?
It seems I need a brand new order.. as I'm getting the message:
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Unable to update challenge :: authorization must be pending",
"status": 400
}
Challenge retrying is specified in RFC8555, but is not supported by boulder/Let's Encrypt.
4 Likes
@pbreed are you attempting this on the same 2 domains, or are you iterating through different domains each time?
If you're using the same 2 domains, you are likely getting confusing results due to cached successful validations.
4 Likes
Yep, but if create a new Key and new account this problem goes away....
I figure the staging server is ok with this kind of abuse...
(I originally forgot to swap the url from production to staging.. so I got myself timed out on the main server oops...)
1 Like
One trick is to get a cert for each domain, then run your combined cert order, the cached validations will all have passed and you'll get your cert. Obviously that's just a workaround but it confirms that all your domains are individually possible to validate.
2 Likes
That's the correct way to do this. The validations are cached to the account.
Another way is to set up a failover DNS record (if your hosting provider supports it), so every subdomain under acmetest.example.com (or similar) points at your test server. Then you can just test sequential domains like test-{test_iteration}.acmetest.example.com and not worry about the validations. I prefer to do that when possible, because you skip the whole account registration process.
Someone above mentioned Pebble. I suggest you try working with that test server. You can install it locally on your network.
The workaround that @webprofusion mentioned is good too.
4 Likes
So When this happens I just recycle to start a new order and it seems to pass the 2nd time.
So my async state machine driven AcmeClient is working... does not burn a task and is pretty easy to use...
Just create a Global Static object
AcmeServletObject AcmeClient(DNSNAMES,ACMEURL);
Where DNSNAME is a comma separated list of names.
ie: "foo.com,www.foo.com,more.foo.com"
and ACMEURL is something like:
"https://acme-staging-v02.api.letsencrypt.org/directory"
And in the back ground system task it manages creating keys, and the acme process for getting and renewing certs. The underlying Crypto and TLS is based on Wolfssl. The rest of the RTOS and webclient stuff is NetBurner. (My company)
If you want your cert to have valid email state etc... you need to also add a small code block to change the defaults for that.
You are sneaking this through on the cached validation. This workaround works for now but ISRG/LetsEncrypt intend to change this behavior in the near future as they enable the new shortened certificates the CA/B forum recently passed.
You should try testing with a local version of pebble (a test server that implements the ACME spec differently) or boulder (what LetsEncrypt runs in production). That should help you figure out what is going on with the incoming connection handling.
5 Likes
Although it's perhaps a fun challenge I'm not entirely convinced that acquiring certs on a constrained device is a good idea (running a server for http challenge responses etc) especially if it means being exposed to the internet.
I'm not sure what the "best practise" for IoT certs is? I'd be tempted to have a device-specific private key that's used to acquire auth tokens against your own API (?), which in turn passes a cert (including private key) back to the device (acquired on the server using DNS validation). While this does mean the private key for that domain validated cert is known by your API server this feel a "better" risk than running a public http server on the device. EV Charging Stations have a similar setup (some have fairly complex certificate flows happening).
2 Likes
The timeout issue I was having with the staging server does not seem to happen with the "normal" server. Also it only seems to happen on IPV6 so this is a rate limit in the routing infrastructure somewhere other than the device. (IE wireshark shows the syn for the third query never got to the device.)
1 Like
There have been many threads about this in the past.
I recall many conversations about how Plex was doing it. I could not find the one I had thought of... but I did find this thread/posting where ISRG staff say "I think the way Plex did it is still considered pretty much best-in-class".
Here are 2 more:
- Using a letsencrypt certificate as a signer - #4 by rg305 [contains ISRG recommendations]
- Trusted Self-Signed Certificates for variable IP addresses
4 Likes
So everything is working with letsencrypt.
What other acme severs should I test against?
You should do local tests against Pebble, which is LetsEncrypt's test server. It tries to implement the ACME protocol differently. A well developed client should work with Pebble and Boulder before testing against live services.
3 Likes
If you're concerned about broad compatibility then try it against something that doesn't cache validations (I think you can configure that in Pebble), that usually flushes things out. ZeroSSL perhaps as it has different timing for things like order status changes so the polling is different (and it uses EAB for the initial account registration).
Smallstep step-ca and Hashicorp vault are the two I run long (month long) integration tests with as they have short cert lifetimes (configurable) and they each have their own quirks. Can be quite some effort to setup though so it depends how comprehensive your level of multi-ca support needs to be.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.