arnavion/acme-azure-function

Azure Function that auto-renews TLS certificates using ACME v2

acme-azure-function's Issues

UpdateCdnCertificateFunction should use a KeyVault secret-changed event trigger rather than a timer trigger

https://docs.microsoft.com/en-us/azure/key-vault/event-grid-overview

https://docs.microsoft.com/en-us/azure/event-grid/event-schema-key-vault

https://docs.microsoft.com/en-us/azure/event-grid/event-handlers#azure-functions

[update-cdn-cert] Use Retry-After when set

For the cdn_custom_domain_secret_set async operation, the management API returns a Retry-After header which the Function ought to honor.

DNS-01 challenge for wildcard certificates?

First, great work!! Very useful for me as I am using F# for all the microservices etc.

I see that you have implemented the HTTP-01 challenge only, but as I want to issue wildcard certificate I would have to use DNS-01 ... Have you done anything in that direction? I guess I have to just replace the part where you put a blob on the storage account with some API calls to Azure DNS (in my case DNS is Azure hosted as well) ..

Support ARI and prefer it over hard-coded "30 days before expiry" calculation

https://datatracker.ietf.org/doc/draft-ietf-acme-ari/

https://letsencrypt.org/2023/03/23/improving-resliiency-and-reliability-with-ari.html

---

$ <<< '14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6' tr -d ':' | xxd -r -p | base64 -w 0 | tr '+/' '-_' | tr -d '='; echo

FC6zF7dYVsuuUAlA5h-vnYsUwsY

$ <<< '03:87:46:a9:33:e6:3c:45:bd:1f:98:14:cd:77:59:85:eb:92' tr -d ':' | xxd -r -p | base64 -w 0 | tr '+/' '-_' | tr -d '='; echo

A4dGqTPmPEW9H5gUzXdZheuS

$ curl -sL 'https://acme-v02.api.letsencrypt.org/directory' | gojq -r .renewalInfo

https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-02/renewalInfo/

$ curl -LD - 'https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-02/renewalInfo/FC6zF7dYVsuuUAlA5h-vnYsUwsY.A4dGqTPmPEW9H5gUzXdZheuS'; echo

HTTP/2 200 
server: nginx
date: Tue, 19 Mar 2024 18:10:18 GMT
content-type: application/json
content-length: 101
cache-control: public, max-age=0, no-cache
link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
retry-after: 21600
x-frame-options: DENY
strict-transport-security: max-age=604800

{
  "suggestedWindow": {
    "start": "2024-03-30T00:37:07Z",
    "end": "2024-04-01T00:37:07Z"
  }
}

---

Does it handle revoked certificates? Then it could be an easier solution to #3

[renew-cert] Check for the existing cert's revocation

... not just its expiry time.

A crate like x509-parser can be used to get the OCSP URL. But there's no pure-Rust crate (ie, not openssl) to do OCSP, so the function would need to talk the OCSP protocol manually with something like der.

Ref:

• X.680 - ASN.1

• X.690 - ASN.1 BER and DER encodings

• RFC6960 - OCSP , especially Appendix A for OCSP-over-HTTP

Consider dropping Durable Functions dependency from AcmeFunction

AcmeFunction finishes fast enough that being durable isn't very important.

Switch logger to use Azure Monitor DCE API

The "Data Collector API" that logs directly to Log Analytics hasn't been updated since 2016, and there is an article about migrating to Azure Monitor's "Logs Ingestion API". The latter uses standard OAuth with SP credentials instead of the bespoke symmetric key method that the former uses.

https://learn.microsoft.com/en-us/azure/azure-monitor/logs/tutorial-logs-ingestion-portal

https://learn.microsoft.com/en-us/azure/azure-monitor/logs/custom-logs-migrate#migration-procedure

https://learn.microsoft.com/en-us/cli/azure/monitor/data-collection/rule

https://learn.microsoft.com/en-us/rest/api/monitor/data-collection-rules/create

[acme] Use Retry-After when set

For "processing" orders and "pending" authorizations, the server can return a Retry-After header which the Function ought to honor.

[renew-cert] Handle multiple authorizations

We expect only one authorization, which works for Let's Encrypt, but in general the server may require multiple authorizations. We should handle that too.

It might require a bunch of restructuring from needing to have multiple challenges in flight at the same time between BeginOrder and EndOrder.