1. The problem I’m having:
We have a running apache and caddy instance, each living in their own world on different external IPs. We want to slowly migrate everything to caddy but we have to keep them both alive for production constraints. So the plan we brainstormed is to make apache a simple reverse proxy to caddy until we are ready to shut it down:
- convert apache virtualhost definitions to the equivalent in a caddyfile
- replace the existing virtual host definition so that all traffic is handled to caddy: here we are having some issues.
2. Error messages and/or full log output:
Error from the browser
SSL_ERROR_RX_RECORD_TOO_LONG
Errors from the caddy logs, should have stripped sensitive data:
{"level":"error","ts":1709209050.5225616,"logger":"tls.obtain","msg":"will retry","error":"[ftp.<redacted>.it] Obtain: [ftp.<redacted>.it] solving challenges: authz https://acme.zerossl.com/v2/DV90/authz/W_7RSOVpYLokEF3t6vJ4-Q has unexpected status; order will fail: invalid (order=https://acme.zerossl.com/v2/DV90/order/VFuDDFB0Nn146Hs43bLo1A) (ca=https://acme.zerossl.com/v2/DV90)","attempt":1,"retrying_in":60,"elapsed":6.182826252,"max_duration":2592000},
{"level":"error","ts":1709209049.821224,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"ftp.<redacted>.it","challenge_type":"tls-alpn-01","status_code":400,"problem_type":"urn:ietf:params:acme:error:malformed","error":"84.247.247.54: Server only speaks HTTP, not TLS"},{"level":"error","ts":1709208012.5871758,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"ftp.<redacted>.it","challenge_type":"tls-alpn-01","status_code":400,"problem_type":"urn:ietf:params:acme:error:connection","error":"84.247.247.54: Error getting validation data"},
{"level":"error","ts":1709209047.3053246,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"ftp.<redacted>.it","challenge_type":"http-01","status_code":403,"problem_type":"urn:ietf:params:acme:error:unauthorized","error":"84.247.247.54: Invalid response from http://ftp.<redacted>.it/.well-known/acme-challenge/hmD_L5m31zvL5MYE4VnZaPVFZx-0Mve__LoSY8BjdBo: 502"},
{"level":"error","ts":1709209047.3054154,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"ftp.<redacted>.it","error":"authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - 84.247.247.54: Invalid response from http://ftp.<redacted>.it/.well-known/acme-challenge/hmD_L5m31zvL5MYE4VnZaPVFZx-0Mve__LoSY8BjdBo: 502","order":"https://acme-v02.api.letsencrypt.org/acme/order/1499062116/248442159267","attempt":1,"max_attempts":3},
{"level":"info","ts":1709209044.3384137,"logger":"tls.obtain","msg":"acquiring lock","identifier":"ftp.<redacted>.it"},
{"level":"info","ts":1709209044.3396912,"logger":"tls.obtain","msg":"lock acquired","identifier":"ftp.<redacted>.it"},
{"level":"info","ts":1709209044.3725355,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["ftp.<redacted>.it"]},
{"level":"info","ts":1709209044.3725798,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["ftp.<redacted>.it"]},
{"level":"info","ts":1709209045.7976952,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"ftp.<redacted>.it","challenge_type":"http-01","ca":"https://acme-v02.api.letsencrypt.org/directory"},
{"level":"info","ts":1709209048.7436318,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"ftp.<redacted>.it","challenge_type":"tls-alpn-01","ca":"https://acme-v02.api.letsencrypt.org/directory"},
{"level":"error","ts":1709209049.821328,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"ftp.<redacted>.it","error":"[ftp.<redacted>.it] authorization failed: HTTP 400 urn:ietf:params:acme:error:malformed - 84.247.247.54: Server only speaks HTTP, not TLS","order":"https://acme-v02.api.letsencrypt.org/acme/order/1499062116/248442166827","attempt":2,"max_attempts":3},
{"level":"info","ts":1709209049.8220773,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["ftp.<redacted>.it"]}
Apache doesn’t seem to log any error, likely indicating that request are proxied correctly.
3. Caddy version:
/ # caddy version
v2.4.0 h1:yHnnbawH2G3ZBP2mAJF4XBLnJanqhULLP/wu01Qi9Io=
4. How I installed and ran Caddy:
a. System environment:
Docker container using the “wrapper” provided by lucaslorentz for automatic caddyfile creation based on docker labels.
d. My complete Caddy config:
compiled caddyfile extracted from the logs of the container. Hopefully redacted correctly.
Some reverse proxies uses the container name since they live in the same docker network of the caddy container.
Don’t be misleaded by the ftp prefix, we are not trying to proxy ftp traffic but just a webui exposed by the upstream ftp server.
2024/02/29 12:26:06 [INFO] New Caddyfile:
{
email it@<redacted>.it
}
ftp.<redacted>.it {
reverse_proxy sftpgo-v2.3.0:8080
respond /web/admin 404
}
5. Links to relevant resources:
Apache conf used:
############################ WEBUI
## Reverse Proxy verso il webserver Caddy v2 su docker
<VirtualHost *:80>
ServerName ftp.<redacted>.it <--- this matches a caddyfile host name
ProxyPass "/" "http://192.168.0.80"
ProxyPassReverse "/" "http://192.168.0.80"
ProxyPreserveHost On
</VirtualHost>
<VirtualHost *:443>
ServerName ftp.<redacted>.it
ProxyPass "/" "https://192.168.0.80:443"
ProxyPassReverse "/" "https://192.168.0.80:443"
ProxyPreserveHost On
</VirtualHost>