Website's certificate can not be certified without IPV4

1. The problem I’m having:

I am trying to deploy the self-hosted gitlab with caddy2 on my server which installed debian bulleye. Due to my terrible ISP, the only public IP my server got based on IPV6. When I visited it, it warned "ERR_SSL_PROTOCOL_ERROR". When I check the systemctl status, it reported the problem which seem as certificate can not be certified without IPV4 resulted.

2. Error messages and/or full log output:

Trying 2409:8a55:2c23:3f91:4cd1:a1e8:e780:8:80…
Connected to gitlab.dowblog.top (2409:8a55:2c23:3f91:4cd1:a1e8:e780:8) port 80 (#0)
GET / HTTP/1.1Host: gitlab.dowblog.topUser-Agent: curl/7.74.0Accept: /
Mark bundle as not supporting multiuse< HTTP/1.1 308 Permanent Redirect< Connection: close< Location: https://gitlab.dowblog.top/< Server: Caddy< Date: Tue, 26 Aug 2025 16:00:07 GMT< Content-Length: 0<
Closing connection 0
Clear auth, redirects to port from 80 to 443Issue another request to this URL: ‘https://gitlab.dowblog.top/’
Trying 2409:8a55:2c23:3f91:4cd1:a1e8:e780:8:443…
Connected to gitlab.dowblog.top (2409:8a55:2c23:3f91:4cd1:a1e8:e780:8) port 443 (#1)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
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 1curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.

3. Caddy version:

\v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=

4. How I installed and ran Caddy:

lcmp script:

a. System environment:

debian bulleyes systemctl

b. Command:

sudo systemctl start caddy

PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.

c. Service/unit/compose file:

caddy.service

For using Caddy with a config file.

Make sure the ExecStart and ExecReload commands are correct

for your installation.

See https://caddyserver.com/docs/install for instructions.

WARNING: This service does not use the --resume flag, so if you

use the API to make changes, they will be overwritten by the

Caddyfile next time the service is restarted. If you intend to

use Caddy’s API to configure it, add the --resume flag to the

caddy run command or use the caddy-api.service file instead.

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target
[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force
TimeoutStopSec=5s
LimitNOFILE=1048576
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target

PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.

d. My complete Caddy config:

gitlab.dowblog.top {
reverse_proxy * unix//var/opt/gitlab/gitlab-workhorse/sockets/socket
}

PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.

5. Links to relevant resources:

sudo nmcli
wlan0: connected to Dong_5G
“Intel 7265”
wifi (iwlwifi), C0:B6:F9:91:19:23, hw, mtu 1500
ip4 default, ip6 default
inet4 192.168.3.23/24
route4 0.0.0.0/0
route4 192.168.3.0/24
inet6 2409:8a55:2c21:a081:5e31:7a23:bdf8:8369/64
inet6 2409:8a55:2c21:a081:4cd1:a1e8:e780:8/128
inet6 fe80::6ac0:4e6e:699:f1ef/64
route6 2409:8a55:2c21:a081::/64
route6 ::/0
route6 fe80::/64
route6 2409:8a55:2c21:a081:4cd1:a1e8:e780:8/128

Can you post the log showing that?

2 Likes

Hi @touchinglie,

Check the DNS A (IPv4) and AAAA (IPv6) records for the website’s domain name.

I already set my IPV6 in my DNS server and it work fine. Domain records will be updated by DDNS as scheduled for my server DOESN’T HAS ANY PUBLIC IPV4 AND STATIC IPV6.

Is the certificate in question issued by a public Certificate Authority?

If yes, then DNS-01 challenge is what must have been used to be issued a certificate, correct?

There seem to be no issued certificates from public Certificate Authorities here crt.sh | gitlab.dowblog.top

Please show the output of each of the following:

  • curl -k -4 -v -Ii https://gitlab.dowblog.top/
  • curl -k -6 -v -Ii https://gitlab.dowblog.top/
  • curl -k -4 -v -Ii http://gitlab.dowblog.top:443/
  • curl -k -6 -v -Ii http://gitlab.dowblog.top:443/

By the way, @touchinglie, it’s critical that you share Caddy logs. There are definitely messages about its attempt to obtain a certificate.

4 Likes

I am sorry for my missing log message, it would be sent yesterday without network problom. Here is full Caddy2’s systemctl log, please search “no IPv4 addresses to try as fallback“ to locate the path of keywords:

● caddy.service - Caddy
     Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2025-08-24 16:50:52 CST; 5min ago
       Docs: https://caddyserver.com/docs/
   Main PID: 13850 (caddy)
      Tasks: 10 (limit: 2345)
     Memory: 4.1M
        CPU: 2.874s
     CGroup: /system.slice/caddy.service
             └─13850 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

Aug 24 16:53:04 myserver caddy[13850]: {"level":"error","ts":1756025584.0135853,"msg":"validating authorization","identifier":"gitlab.dowblog.top","problem":{"type":"urn:ietf:params:acme:error:malformed","title":"","detail":"Unable to contact \"gitlab.dowblog.top\" at \"2409:8a55:2c23:3f91:4cd1:a1e8:e780:8\", no IPv4 addresses to try as fallback","instance":"","subproblems":null},"order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/197516354/26850892854","attempt":1,"max_attempts":3,"stacktrace":"github.com/mholt/acmez/v3.(*Client).ObtainCertificate\n\tgithub.com/mholt/acmez/v3@v3.0.0/client.go:152\ngithub.com/caddyserver/certmagic.(*ACMEIssuer).doIssue\n\tgithub.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477\ngithub.com/caddyserver/certmagic.(*ACMEIssuer).Issue\n\tgithub.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371\ngithub.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue\n\tgithub.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249\ngithub.com/caddyserver/certmagic.(*Config).obtainCert.func2\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:626\ngithub.com/caddyserver/certmagic.doWithRetry\n\tgithub.com/caddyserver/certmagic@v0.21.6/async.go:104\ngithub.com/caddyserver/certmagic.(*Config).obtainCert\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:700\ngithub.com/caddyserver/certmagic.(*Config).ObtainCertAsync\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:505\ngithub.com/caddyserver/certmagic.(*Config).manageOne.func1\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:415\ngithub.com/caddyserver/certmagic.(*jobManager).worker\n\tgithub.com/caddyserver/certmagic@v0.21.6/async.go:73"}
Aug 24 16:53:04 myserver caddy[13850]: {"level":"error","ts":1756025584.0335126,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"gitlab.dowblog.top","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:malformed - Unable to contact \"gitlab.dowblog.top\" at \"2409:8a55:2c23:3f91:4cd1:a1e8:e780:8\", no IPv4 addresses to try as fallback"}
Aug 24 16:53:04 myserver caddy[13850]: {"level":"error","ts":1756025584.0611968,"logger":"tls.obtain","msg":"will retry","error":"[gitlab.dowblog.top] Obtain: [gitlab.dowblog.top] solving challenge: gitlab.dowblog.top: [gitlab.dowblog.top] authorization failed: HTTP 400 urn:ietf:params:acme:error:malformed - Unable to contact \"gitlab.dowblog.top\" at \"2409:8a55:2c23:3f91:4cd1:a1e8:e780:8\", no IPv4 addresses to try as fallback (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":2,"retrying_in":120,"elapsed":131.390142589,"max_duration":2592000}
Aug 24 16:55:04 myserver caddy[13850]: {"level":"info","ts":1756025704.1332645,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"gitlab.dowblog.top"}
Aug 24 16:55:04 myserver caddy[13850]: {"level":"info","ts":1756025704.2867389,"logger":"http","msg":"using ACME account","account_id":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/197516354","account_contact":[]}
Aug 24 16:55:04 myserver caddy[13850]: {"level":"info","ts":1756025704.8706214,"msg":"trying to solve challenge","identifier":"gitlab.dowblog.top","challenge_type":"tls-alpn-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
Aug 24 16:55:15 myserver caddy[13850]: {"level":"error","ts":1756025715.8153763,"msg":"challenge failed","identifier":"gitlab.dowblog.top","challenge_type":"tls-alpn-01","problem":{"type":"urn:ietf:params:acme:error:malformed","title":"","detail":"Unable to contact \"gitlab.dowblog.top\" at \"2409:8a55:2c23:3f91:4cd1:a1e8:e780:8\", no IPv4 addresses to try as fallback","instance":"","subproblems":null},"stacktrace":"github.com/mholt/acmez/v3.(*Client).pollAuthorization\n\tgithub.com/mholt/acmez/v3@v3.0.0/client.go:557\ngithub.com/mholt/acmez/v3.(*Client).solveChallenges\n\tgithub.com/mholt/acmez/v3@v3.0.0/client.go:378\ngithub.com/mholt/acmez/v3.(*Client).ObtainCertificate\n\tgithub.com/mholt/acmez/v3@v3.0.0/client.go:136\ngithub.com/caddyserver/certmagic.(*ACMEIssuer).doIssue\n\tgithub.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477\ngithub.com/caddyserver/certmagic.(*ACMEIssuer).Issue\n\tgithub.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371\ngithub.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue\n\tgithub.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249\ngithub.com/caddyserver/certmagic.(*Config).obtainCert.func2\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:626\ngithub.com/caddyserver/certmagic.doWithRetry\n\tgithub.com/caddyserver/certmagic@v0.21.6/async.go:104\ngithub.com/caddyserver/certmagic.(*Config).obtainCert\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:700\ngithub.com/caddyserver/certmagic.(*Config).ObtainCertAsync\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:505\ngithub.com/caddyserver/certmagic.(*Config).manageOne.func1\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:415\ngithub.com/caddyserver/certmagic.(*jobManager).worker\n\tgithub.com/caddyserver/certmagic@v0.21.6/async.go:73"}
Aug 24 16:55:15 myserver caddy[13850]: {"level":"error","ts":1756025715.8410528,"msg":"validating authorization","identifier":"gitlab.dowblog.top","problem":{"type":"urn:ietf:params:acme:error:malformed","title":"","detail":"Unable to contact \"gitlab.dowblog.top\" at \"2409:8a55:2c23:3f91:4cd1:a1e8:e780:8\", no IPv4 addresses to try as fallback","instance":"","subproblems":null},"order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/197516354/26850919944","attempt":1,"max_attempts":3,"stacktrace":"github.com/mholt/acmez/v3.(*Client).ObtainCertificate\n\tgithub.com/mholt/acmez/v3@v3.0.0/client.go:152\ngithub.com/caddyserver/certmagic.(*ACMEIssuer).doIssue\n\tgithub.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477\ngithub.com/caddyserver/certmagic.(*ACMEIssuer).Issue\n\tgithub.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371\ngithub.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue\n\tgithub.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249\ngithub.com/caddyserver/certmagic.(*Config).obtainCert.func2\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:626\ngithub.com/caddyserver/certmagic.doWithRetry\n\tgithub.com/caddyserver/certmagic@v0.21.6/async.go:104\ngithub.com/caddyserver/certmagic.(*Config).obtainCert\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:700\ngithub.com/caddyserver/certmagic.(*Config).ObtainCertAsync\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:505\ngithub.com/caddyserver/certmagic.(*Config).manageOne.func1\n\tgithub.com/caddyserver/certmagic@v0.21.6/config.go:415\ngithub.com/caddyserver/certmagic.(*jobManager).worker\n\tgithub.com/caddyserver/certmagic@v0.21.6/async.go:73"}

See Caddy on a IPv6-only VPS - this seems like the same problem. The certificate issuer couldn’t reach your server on IPv6, and there is no address to fall back to for IPv4. The problem in that post was the firewall blocking port 80 and 443.

2 Likes

I can only reply once in fifty minute. Here is the result:

radxa@myserver:~$ curl -k -4 -v -Ii https://gitlab.dowblog.top/
* Could not resolve host: gitlab.dowblog.top
* Closing connection 0
curl: (6) Could not resolve host: gitlab.dowblog.top
radxa@myserver:~$ ping gitlab.dowblog.top
PING gitlab.dowblog.top(2409:8a55:2c21:7fc1:4cd1:a1e8:e780:8) 56 data bytes
64 bytes from 2409:8a55:2c21:7fc1:4cd1:a1e8:e780:8: icmp_seq=1 ttl=64 time=0.222 ms
64 bytes from 2409:8a55:2c21:7fc1:4cd1:a1e8:e780:8: icmp_seq=2 ttl=64 time=0.202 ms
^C64 bytes from 2409:8a55:2c21:7fc1:4cd1:a1e8:e780:8: icmp_seq=3 ttl=64 time=0.220 ms

--- gitlab.dowblog.top ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 21900ms
rtt min/avg/max/mdev = 0.202/0.214/0.222/0.009 ms
radxa@myserver:~$ curl -k -4 -v -Ii https://gitlab.dowblog.top/
* Could not resolve host: gitlab.dowblog.top
* Closing connection 0
curl: (6) Could not resolve host: gitlab.dowblog.top
radxa@myserver:~$ curl -k -6 -v -Ii https://gitlab.dowblog.top/
*   Trying 2409:8a55:2c21:7fc1:4cd1:a1e8:e780:8:443...
* Connected to gitlab.dowblog.top (2409:8a55:2c21:7fc1:4cd1:a1e8:e780:8) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  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
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
radxa@myserver:~$ curl -k -4 -v -Ii http://gitlab.dowblog.top:443/
* Could not resolve host: gitlab.dowblog.top
* Closing connection 0
curl: (6) Could not resolve host: gitlab.dowblog.top
radxa@myserver:~$ curl -k -6 -v -Ii http://gitlab.dowblog.top:443/
*   Trying 2409:8a55:2c21:7fc1:4cd1:a1e8:e780:8:443...
* Connected to gitlab.dowblog.top (2409:8a55:2c21:7fc1:4cd1:a1e8:e780:8) port 443 (#0)
> HEAD / HTTP/1.1
> Host: gitlab.dowblog.top:443
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 400 Bad Request
HTTP/1.0 400 Bad Request

<
* Excess found: excess = 48 url = / (zero-length body)
* Closing connection 0
radxa@myserver:~$
1 Like

Yes, that might be the reseaon. But it doesn’t make sense for a another blog work fine in the same machine/caddy2 engine/network env/DNS server……

That means that name does not map to an IPv4 Address.

This makes me question if HTTPS is being served on Port 443, below show HTTP does work.

1 Like

You need to disable the firewall.

Trying curl -v http://gitlab.dowblog.top/ shows a connection timeout when tried from the Netherlands

Remember that Letsencrypt needs to verify the challenge from multiple data centers, and each check needs to work before they give you a certificate.

A single country being blocked in the firewall might mean you do not get certificates

1 Like

Thanks for everyone’s helping, I resolved it by cracking my ISP corp server. And yes, the final problem is my ISP using some cutting edge tech to block server’s IP being ask for an https request.

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