[GH-ISSUE #193] ssl3_get_record:wrong version number #83

Closed
opened 2026-03-13 15:42:57 +03:00 by kerem · 5 comments
Owner

Originally created by @arnydo on GitHub (Oct 29, 2019).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/193

Hello,

Assuming there aren't any additional steps to enable Letsencrypt other than setting the port to 443 and tls to letsencrypt/letsencryptstaging, I am getting the following error when attempting to register.

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

  • HTTP works as expected
  • DNS resolved correctly

Config

[general]
# DNS interface. Note that systemd-resolved may reserve port 53 on 127.0.0.53
# In this case acme-dns will error out and you will need to define the listening interface
# for example: listen = "127.0.0.1:53"
listen = "127.0.0.1:53"
# protocol, "both", "both4", "both6", "udp", "udp4", "udp6" or "tcp", "tcp4", "tcp6"
protocol = "both"
# domain name to serve the requests off of
domain = "acme-dns.XXXXX.net"
# zone name server
nsname = "acme-dns.XXXXX.net"
# admin email address, where @ is substituted with .
nsadmin = "acme-dns.XXXXX.com"
# predefined records served in addition to the TXT
records = [
    # domain pointing to the public IP of your acme-dns server
    "acme-dns.XXXXX.net. A X.X.X.X",
    # specify that auth.example.org will resolve any *.auth.example.org records
    "acme-dns.XXXXX.net. NS acme-dns.XXXXX.net.",
]
# debug messages from CORS etc
debug = true

[database]
# Database engine to use, sqlite3 or postgres
engine = "sqlite3"
# Connection string, filename for sqlite3 and postgres://$username:$password@$host/$db_name for postgres
# Please note that the default Docker image uses path /var/lib/acme-dns/acme-dns.db for sqlite3
connection = "/var/lib/acme-dns/acme-dns.db"
# connection = "postgres://user:password@localhost/acmedns_db"

[api]
# listen ip eg. 127.0.0.1
ip = "0.0.0.0"
# disable registration endpoint
disable_registration = false
# listen port, eg. 443 for default HTTPS
port = "443"
# possible values: "letsencrypt", "letsencryptstaging", "cert", "none"
tls = "letsencryptstaging"
# only used if tls = "cert"
tls_cert_privkey = "/etc/tls/example.org/privkey.pem"
tls_cert_fullchain = "/etc/tls/example.org/fullchain.pem"
# only used if tls = "letsencrypt"
acme_cache_dir = "api-certs"
# CORS AllowOrigins, wildcards can be used
corsorigins = [
    "*"
]
# use HTTP header to get the client ip
use_header = false
# header name to pull the ip address / list of ip addresses from
header_name = "X-Forwarded-For"

[logconfig]
# logging level: "error", "warning", "info" or "debug"
loglevel = "debug"
# possible values: stdout, TODO file & integrations
logtype = "stdout"
# file path for logfile TODO
# logfile = "./acme-dns.log"
# format, either "json" or "text"
logformat = "text"

Command

curl -XPOST https://acme-dns.XXXXX.net/register
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Originally created by @arnydo on GitHub (Oct 29, 2019). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/193 Hello, Assuming there aren't any additional steps to enable Letsencrypt other than setting the port to 443 and tls to letsencrypt/letsencryptstaging, I am getting the following error when attempting to register. ```curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number``` * HTTP works as expected * DNS resolved correctly ## Config ``` [general] # DNS interface. Note that systemd-resolved may reserve port 53 on 127.0.0.53 # In this case acme-dns will error out and you will need to define the listening interface # for example: listen = "127.0.0.1:53" listen = "127.0.0.1:53" # protocol, "both", "both4", "both6", "udp", "udp4", "udp6" or "tcp", "tcp4", "tcp6" protocol = "both" # domain name to serve the requests off of domain = "acme-dns.XXXXX.net" # zone name server nsname = "acme-dns.XXXXX.net" # admin email address, where @ is substituted with . nsadmin = "acme-dns.XXXXX.com" # predefined records served in addition to the TXT records = [ # domain pointing to the public IP of your acme-dns server "acme-dns.XXXXX.net. A X.X.X.X", # specify that auth.example.org will resolve any *.auth.example.org records "acme-dns.XXXXX.net. NS acme-dns.XXXXX.net.", ] # debug messages from CORS etc debug = true [database] # Database engine to use, sqlite3 or postgres engine = "sqlite3" # Connection string, filename for sqlite3 and postgres://$username:$password@$host/$db_name for postgres # Please note that the default Docker image uses path /var/lib/acme-dns/acme-dns.db for sqlite3 connection = "/var/lib/acme-dns/acme-dns.db" # connection = "postgres://user:password@localhost/acmedns_db" [api] # listen ip eg. 127.0.0.1 ip = "0.0.0.0" # disable registration endpoint disable_registration = false # listen port, eg. 443 for default HTTPS port = "443" # possible values: "letsencrypt", "letsencryptstaging", "cert", "none" tls = "letsencryptstaging" # only used if tls = "cert" tls_cert_privkey = "/etc/tls/example.org/privkey.pem" tls_cert_fullchain = "/etc/tls/example.org/fullchain.pem" # only used if tls = "letsencrypt" acme_cache_dir = "api-certs" # CORS AllowOrigins, wildcards can be used corsorigins = [ "*" ] # use HTTP header to get the client ip use_header = false # header name to pull the ip address / list of ip addresses from header_name = "X-Forwarded-For" [logconfig] # logging level: "error", "warning", "info" or "debug" loglevel = "debug" # possible values: stdout, TODO file & integrations logtype = "stdout" # file path for logfile TODO # logfile = "./acme-dns.log" # format, either "json" or "text" logformat = "text" ``` ## Command ``` curl -XPOST https://acme-dns.XXXXX.net/register``` ```curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number```
kerem 2026-03-13 15:42:57 +03:00
  • closed this issue
  • added the
    question
    label
Author
Owner

@joohoi commented on GitHub (Oct 30, 2019):

Having the port 443 accessible from the public internet shouldn't be required anymore with the latest version of acme-dns. I wonder if something went wrong with acquiring the certificate from Let's Encrypt (staging, based on your configuration). I would try deleting the certificate cache directory (pointed by configuration variable acme_cache_dir) and restarting acme-dns while keeping a close eye on the log messages that may indicate something going wrong (or right) with acquiring its own certificate.

<!-- gh-comment-id:547951205 --> @joohoi commented on GitHub (Oct 30, 2019): Having the port 443 accessible from the public internet shouldn't be required anymore with the latest version of `acme-dns`. I wonder if something went wrong with acquiring the certificate from Let's Encrypt (staging, based on your configuration). I would try deleting the certificate cache directory (pointed by configuration variable `acme_cache_dir`) and restarting `acme-dns` while keeping a close eye on the log messages that may indicate something going wrong (or right) with acquiring its own certificate.
Author
Owner

@joohoi commented on GitHub (Oct 30, 2019):

Also I'm wondering if the DNS queries actually resolve from the public internet, as you seem to be binding acme-dns to a local interface:

listen = "127.0.0.1:53"
<!-- gh-comment-id:547952147 --> @joohoi commented on GitHub (Oct 30, 2019): Also I'm wondering if the DNS queries actually resolve from the public internet, as you seem to be binding `acme-dns` to a local interface: ``` listen = "127.0.0.1:53" ```
Author
Owner

@arnydo commented on GitHub (Oct 31, 2019):

Hey @joohoi ,

I am trying to hit the API from inside our network, no the public internet.

I have cleared the cert cache (nothing in there).

The logs don't indicate any errors or activity other than the initial DNS lookup.

Any other ideas to troubleshoot?

Again, using port 80 and no TLS works fine.

<!-- gh-comment-id:548548690 --> @arnydo commented on GitHub (Oct 31, 2019): Hey @joohoi , I am trying to hit the API from inside our network, no the public internet. I have cleared the cert cache (nothing in there). The logs don't indicate any errors or activity other than the initial DNS lookup. Any other ideas to troubleshoot? Again, using port 80 and no TLS works fine.
Author
Owner

@joohoi commented on GitHub (Nov 1, 2019):

Hitting the API from internal network should not make difference here, and having ports other than 53 open to the public internet shouldn't be a requirement anymore, as acme-dns is supposed to acquire its own certificate using the very same DNS challenges than its clients.

Judging by your config.cfg you seem to be using the latest version. Is there any chance you might be running an older acme-dns binary? If you are using Docker, try to do docker pull joohoi/acme-dns:latest, as docker-compose or whatever you might be using to run it doesn't fetch the latest version automatically.

<!-- gh-comment-id:548694401 --> @joohoi commented on GitHub (Nov 1, 2019): Hitting the API from internal network should not make difference here, and having ports other than 53 open to the public internet shouldn't be a requirement anymore, as `acme-dns` is supposed to acquire its own certificate using the very same DNS challenges than its clients. Judging by your `config.cfg` you seem to be using the latest version. Is there any chance you might be running an older `acme-dns` binary? If you are using Docker, try to do `docker pull joohoi/acme-dns:latest`, as `docker-compose` or whatever you might be using to run it doesn't fetch the latest version automatically.
Author
Owner

@arnydo commented on GitHub (Nov 1, 2019):

@joohoi Thank you for taking the time to assist.

I did pull down the latest version when I was having the issues.

However, I went through the install process again today, clearing out all old files and it went through the Lets Encrypt verification process successfully.

It appears to be working well now.

Thank you!!

<!-- gh-comment-id:548788180 --> @arnydo commented on GitHub (Nov 1, 2019): @joohoi Thank you for taking the time to assist. I did pull down the latest version when I was having the issues. However, I went through the install process again today, clearing out all old files and it went through the Lets Encrypt verification process successfully. It appears to be working well now. Thank you!!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/acme-dns#83
No description provided.