Win-acme TLS-ALPN Validation Failing - Unable to activate tcpclient

Help
1

Hello All,

Trying to run Lets Encrypt Validation through TLS for my website and I am getting this error below. Is this a problem with my firewall or could it be an issue with the admin permissions on my server? It worked fine in my homelab where I was able to complete validation but I am having problems in my company's environment.

Add another installation step?:

Plugin IIS generated source covid19.martinrea.com with 1 identifiers
Plugin Single created 1 order
Cached order has status pending, discarding
[covid19.martinrea.com] Authorizing...
[covid19.martinrea.com] Authorizing using tls-alpn-01 validation (SelfHosting)
Unable to activate TcpClient, this may be because of insufficient rights or another application using port 443
[covid19.martinrea.com] Error preparing for challenge answer
[covid19.martinrea.com] Deactivating pending authorization

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: martinrea.com

I ran this command:
using Win-Acme:
9: [tls-alpn] Answer TLS verification request from win-acme

It produced this output:
Add another installation step?:

Plugin IIS generated source covid19.martinrea.com with 1 identifiers
Plugin Single created 1 order
Cached order has status pending, discarding
[covid19.martinrea.com] Authorizing...
[covid19.martinrea.com] Authorizing using tls-alpn-01 validation (SelfHosting)
Unable to activate TcpClient, this may be because of insufficient rights or another application using port 443
[covid19.martinrea.com] Error preparing for challenge answer
[covid19.martinrea.com] Deactivating pending authorization

My web server is (include version):
IIS 1607 OS Build 14393.7428

The operating system my web server runs on is (include version):
Windows Server 2016
My hosting provider, if applicable, is:
Rogers

I can login to a root shell on my machine (yes or no, or I don't know):
No

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Win-Acme 2.2.9.1701

2

Something is currently handling HTTPS requests on port 443 for that domain name. Did you stop it before trying to use the win-acme's stand alone listener for this?

If that is not practical you could try the HTTP or DNS challenges.

https://decoder.link/sslchecker/covid19.martinrea.com/443

2 Likes
3

Hi Mike,

Thanks for your quick response! While running the validation I did stop IIS previously and still ran into the same issue. Is that the wildcard domain that you're referring to or the covid19.martinrea.com one that you're referring to?

1 Like
4

I did not see any wildcard domain in your post. And, TLS-ALPN does not support wildcard names in the cert request (only DNS Challenge does).

I just looked at your covid19 domain and see something is listening on it right now. Although, I see an actual HTTPS request to that name timesout although an openssl request gets through. Not sure if that is why TLS-ALPN would have problems. The win-acme, Windows, TLS-ALPN combination is not something I know much about out.

The error message seemed pretty clear though that win-acme could not open port 443 to setup the tls-alpn challenge.

Perhaps another volunteer will have more insight

If you have a wildcard why do you need a cert for the discrete covid19 name?

echo|openssl s_client covid19.martinrea.com:443 | head
---
Certificate chain
 0 s:CN = *.martinrea.com
   i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct 10 00:00:00 2024 GMT; NotAfter: Aug 28 23:59:59 2025 GMT
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
3 Likes
5

HI Mike,

Ahh that makes sense! So its probably something else that is pulling that specific covid19.martinrea.com host. Also we're trying to get rid of the wild card cert and go with more specific ones, also automate all of this hence why we wanted to go with acme/letsencrypt.

I would be open to more information as far as what we could look for. I completely shut down the website in IIS, waited like 5-10 min and still had issues which is why I am confused.

1 Like
6

Can you just use the HTTP Challenge? That is far more common and uses the running IIS server to satisfy the challenge.

Windows also has a shared system listener which is what I don't understand well. I just know it can have impact.

win-acme is a nice client but Certify the Web is more popular and has a gui. It is well integrated with IIS. It might be worth a look at that. Or, wait for a Windows expert to explain the above quirks better :slight_smile:

3 Likes
7

HI MIke,

Ahh the challenge here is HTTP is blocked on our company's network for security purposes and I dont think I'll be able to get it whitelisted. Does it need to use HTTP every single time? I've used Certify the Web before as well, does it have other validation options?

8

LE supports three authentication methods:

  • HTTP
  • TLS-ALPN
  • DNS

Has your IT department already handled any ACME certificate validations?
If so, then you should follow their advice.
If not, they need to step-up and get with the program - LOL

2 Likes
9

Hi Rg305,

This is something new we are testing and rolling out so no. I am the first one in our organization trying this. We were able to get it working on my home lab but that is basically unrestricted other than port forward. Are the other LE users all whitelisting HTTP 24/7 or are they only doing it while the renewal occurs? Our IT Security Team won't whitelist HTTP unfortunately and DNS validation doesn't work for our DNS provider.

11

I'd say both.

If you understand network security, you can see that allowing HTTP [24/7] to a specific host and only have that host run an ACME client on port 80 is about as safe as it can get.

If you are more paranoid than most [as am I], you could dedicate one specific system just for the handling of all the ACME challenges [a certificate management system]. It could be placed in a DMZ and only accessed for the HTTP authentication challenges and for whatever secure method you choose to retrieve the cert files from it.

Also, note that if your security allows for HTTPS access [not sure if it does or doesn't, but if so], then allowing this HTTP access is no less secure than that.

3 Likes
12

tls-alpn-01 requires exclusive use of port 443 so it can control the TLS conversation, which on windows means fighting a combination of schannel and http.sys configuration. I just wouldn't use it on Windows, especially with IIS installed.

HTTP domain validation is fine but some orgs just blanket block port 80 as security posture. An application aware firewall could allow incoming http /.well-known/acme-challenge requests and block all other requests.

To get DNS validation working you can CNAME your domains _acme-challenge record to a TXT record in another zone (e.g.acme-auth.yourdomain.com) and host that zone on a supported provider, like AWS Route 53 or whoever you cloud provider is.

I don't know how you tell win-acme to delegate to another zone but in Certify The Web you would use a CNAME delegation rule: DNS Validation (dns-01) | Certify The Web Docs - there are also other DNS challenge delegation options like hosting your own acme-dns or using Certify DNS for challenge responses.