[OT?] Verification failed using LettuceEncrypt, succes with win-acme

Hi,

I understand this question migt be out of topics but still, I hope somene might now at least point me to a place where to ask. I'm aware that problem is related to 3rd party library but I do hope somene will recognize the problem and help me out,

I have a (blazor C#) server that uses LettuceEncrypt to create/maintain Lets's enyrpt certificate on our server. I simply can't make it work. FYI I do get a valid certtificate using win-acme on the same server so I don't think it is a server/DNS configuration issue.

The first error I get in verbose log is "Connection reset by peer, Code = BadRequest" (more details below). My server has both 80 and 443 ports open, but my application is set to listen at different https port, say 7990 onyl.

Any ideas?
Goran

2025-02-12 10:14:19.060 +01:00 [VRB] ACMEv2 action: FetchAuthorizationDetails, "https://acme-v02.api.letsencrypt.org/acme/authz/2223937125/474788126585"
2025-02-12 10:14:19.245 +01:00 [VRB] ACMEv2 action: GetAuthorization
2025-02-12 10:14:19.254 +01:00 [ERR] Failed to validate ownership of domainName 'rest.alba.si'. Reason: urn:ietf:params:acme:error:connection: 193.189.171.67: Connection reset by peer, Code = BadRequest
2025-02-12 10:14:19.265 +01:00 [DBG] Validation with TlsAlpn01DomainValidator failed with error: Failed to validate ownership of domainName 'rest.alba.si'
System.InvalidOperationException: Failed to validate ownership of domainName 'rest.alba.si'
   at LettuceEncrypt.Internal.DomainOwnershipValidator.WaitForChallengeResultAsync(IAuthorizationContext authorizationContext, CancellationToken cancellationToken)
   at LettuceEncrypt.Internal.TlsAlpn01DomainValidator.ValidateOwnershipAsync(IAuthorizationContext authzContext, CancellationToken cancellationToken)
   at LettuceEncrypt.Internal.AcmeCertificateFactory.ValidateDomainOwnershipAsync(IAuthorizationContext authorizationContext, CancellationToken cancellationToken)

First, LettuceEncrypt doesn't look like something to start using today. It is no longer being maintained. From the github:

This project is in maintenance mode. I lost interest in developing features. I will make a patch if there is a security issue. I'll also consider an update if a new .NET major version breaks and the patch fix required is small.

There are significant new features (ARI and Profiles) that you would not have support for.

The ReadMe says it only works with Kestrel server and only when Kestrel is the edge server. I don't know enough about your configuration but you didn't mention Kestrel and I see an IIS server at the edge (on port 443).

As to the problem ... this log snip looks like a TLS-ALPN-01 challenge was tried and failed. Did you use TLS-ALPN when trying win-acme?

The TLS-ALPN challenge is sent from Let's Encrypt server to your domain on port 443. Whatever sees that (IIS?) must handle that correctly. Either by replying directly or forwarding to whatever can. I have no expertise on if/how IIS could forward TLS-ALPN to a different server / port on your system.

Can you use an HTTP Challenge instead? That would seem a lot easier to manage. Or, possibly a DNS Challenge.

2 Likes

If your app is using LettuceEncrypt middleware it will still need to provide challenge responses on either port 80:

  • port 80: http domain validation
  • port 443: TlsAlpn01, which temporarily performs a special TLS handshake to validate your domain control

If your app is not listening on those ports it can't complete the ACME challenges, unless you use DNS validation etc instead.

Additionally if you have IIS installed I don't think you will be able to share port 443 to complete a TlsAlpn01 challenge.

My suggestion would be to use win-acme/simple-acme or https://certifytheweb.com (which I develop) to manage your actual certs, and export the cert to a known location that your app can pickup. Then periodically restart your app service so it always has the fresh certificate (e.g. weekly or monthly), or do it on demand when the cert changes with a dotnet filewatcher etc. Other strategies include pushing renewed certs to a secrets vault and having your app fetch from that periodically. [Edit: see also YARP, which is an ACME aware dotnet reverse proxy]

Note also that win-acme is deprecated by the developer, who is moving their work to simple-acme.com

1 Like

@MikeMcQ and @webprofusion

Thank you both very much for your entries. Looks like I felt on (package) bannana. LettuceEncrypt was introduced by another deceloper as simple as reliable solution and I admmit I didn't check its state on GIT. My bad.

For potentonal readers, I do use Kestrel as edge server in my appliaction.

After reading your answers I did what's most obvious - I abandoned LettuceEncrypt all together, created certificate in file store using win-acme and everything works like a charm.

I will investigate simple-ame and Certify Certificate Manager in the near future, but at the end is just a decision t let dedicated software do the job.

Thank you
Gorc

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.