Multiple websites on one server: Cloudflare error 525

1. Caddy version (caddy version):

v2.3.0

2. How I run Caddy:

Same as below?

a. System environment:

Debian 10

b. Command:

sudo service caddy reload

d. My complete Caddyfile or JSON config:

www.domainone.com {
  redir https://domainone.com{uri}
}
domainone.com {
  root * /home/user/www/domainone.com
  file_server
}

www.domaintwo.com {
  redir https://domaintwo.com{uri}
}
domaintwo.com {
  root * /home/user/www/domaintwo.com
  file_server
}

3. The problem I’m having:

I am using Cloudflare for both domains. The first domain works fine, but on the second domain I am getting Error 525, SSL handshake failed.

Looks like SSL is only working on the first domain.

4. Error messages and/or full log output:

Jun 02 17:21:52 username caddy[5052]: {"level":"error","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"www.exampletwo.com","error":"authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - Invalid response from https://www.exampletwo.com/.well-known/acme-challenge/xxxx [xxxx]: \"<!DOCTYPE html>\\n<!--[if lt IE 7]> <html class=\\\"no-js ie6 oldie\\\" lang=\\\"en-US\\\"> <![endif]-->\\n<!--[if IE 7]>    <html class=\\\"no-js \"","order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/xxxx/xxxx","attempt":1,"max_attempts":3}

Jun 02 17:21:54 username caddy[5052]: {"level":"info","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"www.exampletwo.com","challenge_type":"tls-alpn-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}

Jun 02 17:21:55 username caddy[5052]: {"level":"error","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"www.exampletwo.com","challenge_type":"tls-alpn-01","status_code":403,"problem_type":"urn:ietf:params:acme:error:unauthorized","error":"Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge"}

Jun 02 17:21:55 username caddy[5052]: {"level":"error","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"www.exampletwo.com","error":"authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge","order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/xxxx/xxxx","attempt":2,"max_attempts":3}

Jun 02 17:21:59 username caddy[5052]: {"level":"info","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"www.exampletwo.com","challenge_type":"http-01","ca":"https://acme.zerossl.com/v2/DV90"}

Jun 02 17:26:37 username caddy[5052]: {"level":"error","ts":xxxx,"logger":"tls.obtain","msg":"will retry","error":"[exampletwo.com] Obtain: [exampletwo.com] solving challenges: [exampletwo.com] authorization took too long (order=https://acme.zerossl.com/v2/DV90/order/xxxx) (ca=https://acme.zerossl.com/v2/DV90)","attempt":6,"retrying_in":1200,"elapsed":3134.601656254,"max_duration":2592000}
$ curl -svo /dev/null https://domaintwo.com --connect-to ::ipaddress 2>&1 | egrep -v "^{.*$|^}.*$|^* http.*$"
* Expire in 0 ms for 6 (transfer 0x...)
* Connecting to hostname: ipaddress
*   Trying ipaddress...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x...)
* Connected to ipaddress (ipaddress) port 443 (#0)
* ALPN, offering h2
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
* Closing connection 0

5. What I already tried:

I researched these forums and found this:

Unfortunately it didn’t help.

Please update to the latest version, v2.4.1

I don’t see any logs. Where are your logs?

If you have Caddy running as a systemd service, you can see them with this command:

journalctl -u caddy --no-pager | less

That’s from Caddy v1, well outdated.

Thanks, I updated the error with your command’s output.

I’ll try to update it when I have some time. I really hope I won’t mess everything up.

I am pasting the error here, which I also added in the opening message.

Jun 02 17:21:52 username caddy[5052]: {"level":"error","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"www.exampletwo.com","error":"authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - Invalid response from https://www.exampletwo.com/.well-known/acme-challenge/xxxx [xxxx]: \"<!DOCTYPE html>\\n<!--[if lt IE 7]> <html class=\\\"no-js ie6 oldie\\\" lang=\\\"en-US\\\"> <![endif]-->\\n<!--[if IE 7]>    <html class=\\\"no-js \"","order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/xxxx/xxxx","attempt":1,"max_attempts":3}

Jun 02 17:21:54 username caddy[5052]: {"level":"info","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"www.exampletwo.com","challenge_type":"tls-alpn-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}

Jun 02 17:21:55 username caddy[5052]: {"level":"error","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"www.exampletwo.com","challenge_type":"tls-alpn-01","status_code":403,"problem_type":"urn:ietf:params:acme:error:unauthorized","error":"Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge"}

Jun 02 17:21:55 username caddy[5052]: {"level":"error","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"www.exampletwo.com","error":"authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge","order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/xxxx/xxxx","attempt":2,"max_attempts":3}

Jun 02 17:21:59 username caddy[5052]: {"level":"info","ts":xxxx,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"www.exampletwo.com","challenge_type":"http-01","ca":"https://acme.zerossl.com/v2/DV90"}

Jun 02 17:26:37 username caddy[5052]: {"level":"error","ts":xxxx,"logger":"tls.obtain","msg":"will retry","error":"[exampletwo.com] Obtain: [exampletwo.com] solving challenges: [exampletwo.com] authorization took too long (order=https://acme.zerossl.com/v2/DV90/order/xxxx) (ca=https://acme.zerossl.com/v2/DV90)","attempt":6,"retrying_in":1200,"elapsed":3134.601656254,"max_duration":2592000}

Do you have something like Cloudflare in front of that domain? Looks like something is intercepting the ACME requests and responding incorrectly.

Yes, I have Cloudflare. Settings are exactly the same as for the first domain.

First domain is working perfectly though, so thought the problem was with Caddy.

Sorry, double reply.
I tried this and got an error:

$ curl -svo /dev/null https://domaintwo.com --connect-to ::ipaddress 2>&1 | egrep -v "^{.*$|^}.*$|^* http.*$"
* Expire in 0 ms for 6 (transfer 0x...)
* Connecting to hostname: ipaddress
*   Trying ipaddress...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x...)
* Connected to ipaddress (ipaddress) port 443 (#0)
* ALPN, offering h2
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
* Closing connection 0

I’ve been researching around but nothing is working. I tried changing Cloudflare to flexible, but nothing.

No worries, that’s not a rule here :slight_smile:

Did you check that the DNS records are correct?

Hehe it always feels a little rude to double post. :slight_smile:

I set up DNS exactly the same as domainone. IP address is the same.

Just an A record and a CNAME record.

What did you make of the error above?

* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

That just means Caddy doesn’t have a certificate that it can use to solve the TLS handshake. Your logs from earlier showed that it couldn’t complete issuance because something was intercepting the ACME requests before it could reach Caddy.

I just compared my Cloudflare settings between domainone and domaintwo, and they are identical.

Do you think there is a possibility that the problem is with Caddy, instead of Cloudflare? I don’t get why domainone is working, but domaintwo no.

No, this message makes it very clear it’s a problem outside of Caddy:

Caddy does not respond with HTML to requests for /.well-known/acme-challenge.

1 Like

Especially not HTML geared for Internet Explorer 6.

This seems to be the error message that Cloudflare is returning.
I’m also dealing with Cloudflare, so I deliberately gave an error:

<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en-US"> <![endif]-->
<!--[if IE 7]>    <html class="no-js ie7 oldie" lang="en-US"> <![endif]-->
<!--[if IE 8]>    <html class="no-js ie8 oldie" lang="en-US"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en-US"> <!--<![endif]-->
<head>
<title>(ERROR HEADER) | Cloudflare</title>
<meta charset="UTF-8" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1" />
                            :

If you have Cloudflare proxy enabled, http authentication of the certificate will fail
This is a problem you will experience when using Cloudflare, not just Caddy.

You need to do one of the following:

3 Likes

I can’t believe it finally worked. What a nightmare this was. A massive thanks to everyone that helped! I followed your first solution, by applying Cloudflare Origin Certificate.

I only have one small problem!

So this is what my Caddyfile looks like right now:

www.siteone.com {
  redir https://siteone.com{uri}
}
siteone.com {
  root * /home/user/www/siteone.com
  file_server
}

www.sitetwo.com {
  redir https://sitetwo.com{uri}
}
sitetwo.com {
  tls /etc/ssl/certs/sitetwo.com.pem /home/user/tmp/sitetwo.com.key.pem
  root * /home/user/www/sitetwo.com
  file_server
}

I figured that the error I was getting when doing sudo service caddy reload was due to the permissions of /etc/ssl/private/, so I moved the key file in a tmp directory in the home and it just worked.

Is there a way to allow caddy to access /etc/ssl/private/, so at least I am doing things properly? Or it doesn’t matter where I keep the key?

Also, how come siteone is working without any of this? I’m genuinely curious.

1 Like

Caddy runs as the caddy user, when running as a service. Make sure that user can read from those locations.

Impossible to say, you own the keys to your setup. And you obfuscated your domains, so there’s no way for us to do any digging of our own.

1 Like

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