Not getting SSL certificate for domain

dmikester1 · October 24, 2022, 2:25am

1. Output of `caddy version`:

v2.5.1 h1:bAWwslD1jNeCzDa+jDCNwb8M3UJ2tPa8UZFFzPVmGKs=

2. How I run Caddy:

Caddy Windows Service - powered by WinSW

a. System environment:

Windows Server 2019

b. Command:

Paste command here.

c. Service/unit/compose file:

n/a

d. My complete Caddy config:

ecgrowapi.com {
	respond "ecgrowapi.com Caddy Server response"
	
	#handle_path /api* {
	#	reverse_proxy localhost:3001
	#}

	#handle {
	#	root * C:\Web\Webs\ExternalWeb
	#	encode gzip
	#	file_server
	#}
}

3. The problem I’m having:

We have a domain, ecgrowapi.com and the https was working just fine. I was doing some work enabling and disabling internet access on this server as I was doing work and for some reason the SSL cert stopped working. It seems like the challenge is failing for some reason in the logs.

4. Error messages and/or full log output:

C:\Web\caddy>2022/10/24 02:13:04.280    WARN    exiting; byeee!! 👋     {"signal": "SIGINT"}
2022/10/24 02:13:04.309 INFO    tls.cache.maintenance   stopped background certificate maintenance      {"cache": "0xc00095bce0"}
2022/10/24 02:13:04.309 WARN    tls.issuance.acme.acme_client   HTTP request failed; retrying   {"url": "https://acme.zerossl.com/v2/DV90/authz/D4iF4U7QeyQrdWQKY1qnUA", "error": "performing request: Post \"https://acme.zerossl.com/v2/DV90/authz/D4iF4U7QeyQrdWQKY1qnUA\": context canceled"}
2022/10/24 02:13:04.311 WARN    tls.issuance.acme.acme_client   HTTP request failed; retrying   {"url": "https://acme.zerossl.com/v2/DV90/authz/D4iF4U7QeyQrdWQKY1qnUA", "error": "performing request: Post \"https://acme.zerossl.com/v2/DV90/authz/D4iF4U7QeyQrdWQKY1qnUA\": context canceled"}
2022/10/24 02:13:04.311 ERROR   tls.issuance.acme.acme_client   deactivating authorization      {"identifier": "ecgrowapi.com", "authz": "https://acme.zerossl.com/v2/DV90/authz/D4iF4U7QeyQrdWQKY1qnUA", "error": "attempt 1: https://acme.zerossl.com/v2/DV90/authz/D4iF4U7QeyQrdWQKY1qnUA: context canceled"}
2022/10/24 02:13:04.311 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "ecgrowapi.com", "issuer": "acme.zerossl.com-v2-DV90", "error": "[ecgrowapi.com] solving challenges: [ecgrowapi.com] checking authorization status: attempt 1: https://acme.zerossl.com/v2/DV90/authz/D4iF4U7QeyQrdWQKY1qnUA: context canceled (order=https://acme.zerossl.com/v2/DV90/order/xls2NcBZnFekwtQiqKkr-Q) (ca=https://acme.zerossl.com/v2/DV90)"}
2022/10/24 02:13:04.312 INFO    tls.obtain      releasing lock  {"identifier": "ecgrowapi.com"}
2022/10/24 02:13:04.312 ERROR   tls.obtain      unable to unlock        {"identifier": "ecgrowapi.com", "lock_key": "issue_cert_ecgrowapi.com", "error": "remove C:\\Users\\Administrator\\AppData\\Roaming\\Caddy\\locks\\issue_cert_ecgrowapi.com.lock: The system cannot find the file specified."}
2022/10/24 02:13:04.323 ERROR   tls     job failed      {"error": "ecgrowapi.com: obtaining certificate: [ecgrowapi.com] Obtain: [ecgrowapi.com] solving challenges: [ecgrowapi.com] checking authorization status: attempt 1: https://acme.zerossl.com/v2/DV90/authz/D4iF4U7QeyQrdWQKY1qnUA: context canceled (order=https://acme.zerossl.com/v2/DV90/order/xls2NcBZnFekwtQiqKkr-Q) (ca=https://acme.zerossl.com/v2/DV90)"}
2022/10/24 02:13:04.324 INFO    admin   stopped previous server {"address": "tcp/localhost:2019"}
2022/10/24 02:13:04.324 INFO    shutdown complete       {"signal": "SIGINT", "exit_code": 0}

5. What I already tried:

Tried different options in the caddyfile.

6. Links to relevant resources:

matt · October 24, 2022, 2:32am

Looks like you’re shutting down the server, so it’s cleaning up its resources, including shutting down outstanding connections.

dmikester1 · October 24, 2022, 2:36am

That’s odd. I’m certainly not doing anything intentional to shut down the server. I have stopped the service and and I am simply trying to start it from the command line using ‘caddy start’.

dmikester1 · October 24, 2022, 2:38am

It just sits on this line:

2022/10/24 02:35:15.156 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "ecgrowapi.com", "challenge_type": "http-01", "ca": "https://acme.zerossl.com/v2/DV90"}

matt · October 24, 2022, 6:45pm

I think I need more context; specifically a way to reproduce the exact behavior you’re seeing.

I have a lot of questions. What was being done? The certificate will be reused as long as it’s valid, and public certs are valid for 90 days. Caddy won’t even try to get a new one unless it’s nearing expiration or can’t find an old one.

That’s fine, but Caddy is receiving SIGINT either way:

2022/10/24 02:13:04.280    WARN    exiting; byeee!! 👋     {"signal": "SIGINT"}

What are the full logs when you run Caddy? How can I reproduce this at home?

dmikester1 · October 24, 2022, 8:04pm

Thank you for the response.
What I was doing was basically switching between DHCP and a static IP on the Ethernet adapter to enable and disable Internet on this server. The folks who set up this web server on this network wanted it as locked down as possible because it would be public facing, so they disabled the Internet by putting in that static IP. I had to enable it a few times as I was downloading packages, etc for my code. So somewhere along the line, the SSL stopped working.

Does this server need full time permanent access to the www for Caddy to work?

Hopefully this is enough logs:

2022/10/24 09:38:04.248 INFO    tls.issuance.zerossl    generated EAB credentials       {"key_id": "2gQ0TUPhDVQlfwcsqoY2Fw"}
2022/10/24 09:38:07.104 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "ecgrowapi.com", "challenge_type": "http-01", "ca": "https://acme.zerossl.com/v2/DV90"}
2022/10/24 09:43:12.582 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "ecgrowapi.com", "issuer": "acme.zerossl.com-v2-DV90", "error": "[ecgrowapi.com] solving challenges: [ecgrowapi.com] authorization took too long (order=https://acme.zerossl.com/v2/DV90/order/buikW7niW1iQNQklQWFEsg) (ca=https://acme.zerossl.com/v2/DV90)"}
2022/10/24 09:43:12.582 ERROR   tls.obtain      will retry      {"error": "[ecgrowapi.com] Obtain: [ecgrowapi.com] solving challenges: [ecgrowapi.com] authorization took too long (order=https://acme.zerossl.com/v2/DV90/order/buikW7niW1iQNQklQWFEsg) (ca=https://acme.zerossl.com/v2/DV90)", "attempt": 12, "retrying_in": 21600, "elapsed": 25687.7865665, "max_duration": 2592000}
2022/10/24 15:43:13.170 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "ecgrowapi.com", "challenge_type": "tls-alpn-01", "ca": "https://acme-staging-v02.api.letsencrypt.org/directory"}
2022/10/24 15:43:23.590 ERROR   tls.issuance.acme.acme_client   challenge failed        {"identifier": "ecgrowapi.com", "challenge_type": "tls-alpn-01", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "173.245.132.218: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": []}}
2022/10/24 15:43:23.590 ERROR   tls.issuance.acme.acme_client   validating authorization        {"identifier": "ecgrowapi.com", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "173.245.132.218: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": []}, "order": "https://acme-staging-v02.api.letsencrypt.org/acme/order/54430114/4746667554", "attempt": 1, "max_attempts": 3}
2022/10/24 15:43:24.728 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "ecgrowapi.com", "challenge_type": "http-01", "ca": "https://acme-staging-v02.api.letsencrypt.org/directory"}
2022/10/24 15:43:35.187 ERROR   tls.issuance.acme.acme_client   challenge failed        {"identifier": "ecgrowapi.com", "challenge_type": "http-01", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "173.245.132.218: Fetching http://ecgrowapi.com/.well-known/acme-challenge/iT2Gi7J_PSx9vF0ZF2UoP_4EW-3XZ2MN8g0zcJ0Dgfk: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": []}}
2022/10/24 15:43:35.187 ERROR   tls.issuance.acme.acme_client   validating authorization        {"identifier": "ecgrowapi.com", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "173.245.132.218: Fetching http://ecgrowapi.com/.well-known/acme-challenge/iT2Gi7J_PSx9vF0ZF2UoP_4EW-3XZ2MN8g0zcJ0Dgfk: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": []}, "order": "https://acme-staging-v02.api.letsencrypt.org/acme/order/54430114/4746670194", "attempt": 2, "max_attempts": 3}
2022/10/24 15:43:35.188 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "ecgrowapi.com", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "HTTP 400 urn:ietf:params:acme:error:connection - 173.245.132.218: Fetching http://ecgrowapi.com/.well-known/acme-challenge/iT2Gi7J_PSx9vF0ZF2UoP_4EW-3XZ2MN8g0zcJ0Dgfk: Timeout during connect (likely firewall problem)"}
2022/10/24 15:43:35.188 WARN    tls.issuance.zerossl    missing email address for ZeroSSL; it is strongly recommended to set one for next time
2022/10/24 15:43:37.993 INFO    tls.issuance.zerossl    generated EAB credentials       {"key_id": "FREVNYAs5f2JfmBcOvBZCQ"}
2022/10/24 15:43:43.008 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "ecgrowapi.com", "challenge_type": "http-01", "ca": "https://acme.zerossl.com/v2/DV90"}
2022/10/24 15:48:48.457 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "ecgrowapi.com", "issuer": "acme.zerossl.com-v2-DV90", "error": "[ecgrowapi.com] solving challenges: [ecgrowapi.com] authorization took too long (order=https://acme.zerossl.com/v2/DV90/order/YYk7cwOGApuSMbj-d-9B8Q) (ca=https://acme.zerossl.com/v2/DV90)"}
2022/10/24 15:48:48.457 ERROR   tls.obtain      will retry      {"error": "[ecgrowapi.com] Obtain: [ecgrowapi.com] solving challenges: [ecgrowapi.com] authorization took too long (order=https://acme.zerossl.com/v2/DV90/order/YYk7cwOGApuSMbj-d-9B8Q) (ca=https://acme.zerossl.com/v2/DV90)", "attempt": 13, "retrying_in": 21600, "elapsed": 47623.5066411, "max_duration": 2592000}

I should add in my entire caddyfile including the commented code, I had that code in earlier, and now have commented it when trying to get this to work.

ecgrowapi.com {
	respond "ecgrowapi.com Caddy Server response"
	
	#handle_path /api* {
	#	reverse_proxy localhost:3001
	#}

	#handle {
	#	root * C:\Web\Webs\ExternalWeb
	#	encode gzip
	#	file_server
	#}
}

#:3001 {
#	tls internal
#}

#externalweb.ecgrow.local {
	#tls internal
	#handle_path /api* {
	#	reverse_proxy localhost:3001
	#}

	#handle {
	#	root * C:\Web\Webs\ExternalWeb
	#	encode gzip
	#	file_server
	#}
#}

#localhost {
	#tls internal
#	handle_path /api* {
#		reverse_proxy localhost:3001
#	}

#	handle {
#		root * C:\Web\Webs\ExternalWeb
#		file_server
#	}
#}

Also, not sure if this matters, but my folder: C:\Users\Administrator\AppData\Roaming\Caddy\certificates\local only has folders for externalweb.ecgrow.local and localhost. I do not see a folder for ecgrowapi.com.

dmikester1 · October 24, 2022, 9:21pm

I punched in some of the URL’s from the logs. When I punch this one in:
https://acme-v02.api.letsencrypt.org/acme/order/547550556/137623626007
it says status: “invalid”. Not sure if that has anything to do with it?

matt · October 24, 2022, 11:18pm

Right, so your challenges are failing because the CA couldn’t connect to your server:

Make sure your DNS and network are both properly configured so that the CA can reach Caddy.

No. But Caddy needs to be reachable by the outside in order to obtain TLS certificates. This is not unique to Caddy, this is true of any web servers using ACME / Let’s Encrypt. Unless you enable the DNS Challenge, which does not require external access.

I would read this page:

francislavoie · October 25, 2022, 1:11am

To clarify, are you saying you’re preventing your server from making external requests to the internet, or you’re preventing external requests incoming to your server? (I think Matt understood the latter, but I think you mean the former).

Yes, Caddy does need to have access to the internet to connect to ACME issuers to get a certificate issued.

Technically it only needs it when issuance happens (i.e. every ~60 days) but honestly you’re better off leaving it on all the time.

dmikester1 · October 25, 2022, 2:06am

We have set this server up as a DMZ which means locked down with no access to the Internet so you can’t go anywhere on the Internet from that server. We have our URL ecgrowapi.com sending all traffic to that server. But you are saying we will need to give it Internet access to get those certificates every 60 days.

dmikester1 · October 25, 2022, 2:52pm

OK, so we finally got this working, it was indeed DNS/Firewall settings issues. And we do have outgoing Internet working on that server too so getting renewed certs should be no problem. Thank you guys for all your help!

matt · October 25, 2022, 4:46pm

Excellent. Glad it is working!

system · November 23, 2022, 2:25am

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