Standard_init_linux.go:207: exec user process caused "exec format error"

I'm trying to setup HTTPS for a HomeAssistant configuration. Using DuckDNS.org as DNS registry to resolve the dynamic IP of my ISP with the duckdns.org subdomain.

The installation is on a Raspberry PI. The raspberry is running HomeAssistant (WebUI port 8123) and Pi-hole (WebUI port 80).

Forwarded external port 8321 to internal port 8123 on the router. Trying to run the certbot docker instance to get going (as per the instructions).

Executing the certbot command with port combination 8123:8321 returns:

Error response from daemon: driver failed programming external connectivity on endpoint certbot (a907a8bec71db3d41aabd8ff4d096c93e821739c843284fcba3875090a70cb09): Error starting userland proxy: listen tcp 0.0.0.0:8123: bind: address already in use.

Executing the certbot command with port combination 81:8321 returns:

standard_init_linux.go:207: exec user process caused "exec format error"

My domain is: grembeirn.duckdns.org

I ran this command: sudo docker run -it --rm -p 81:8321 --name certbot -v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" quay.io/letsencrypt/letsencrypt:latest certonly --standalone --standalone-supported-challenges http-01 --email myemail@email.com -d grembeirn.duckdns.org

It produced this output: standard_init_linux.go:207: exec user process caused "exec format error"

My web server is (include version): HomeAssistant

The operating system my web server runs on is (include version): Debian Buster (Raspbian)

My hosting provider, if applicable, is: local host

I can login to a root shell on my machine (yes or no, or I don't know): yes, locally

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 0.31.0

Hi @Wiggum127

that's unrelevant. You can do that, but you can't create a certificate.

A working port 80 is required.

Please read

and

That's

a second problem (you are doing completely wrong things if you want to use the same port with different programs), but that's not relevant because of the first problem. You can't use port 81.

1 Like

Having read the suggested articles, I'm still none the wiser what I should be doing.

Bottom line, there is a dns entry and a site running locally listening on 8123.

Based on the details available, Any pointer What should I do to get an HTTPS setup running? If Certbot can only deal with port 80, it's of no use, I guess.

The HTTP-01 challenge (proving that you own the name) needs to happen over port 80. If you're using another port (and can't have 80 open to fulfill that challenge), you'll need to use the DNS-01 challenge. I think there might be a certbot plugin to do so with DuckDNS?

1 Like

If port 80 isn't available and DNS isn't able to fulfill the challenge, you can also try TLS-ALPN.
But that is not (yet) supported by certbot, so you would have to use another client [like: acme.sh]

Just to address this point individually in case anybody else comes across it: I think this is most likely because that particular quay.io Docker image is for amd64 hardware only. An arm device like a Raspberry Pi cannot execute it.

The image is outdated as well:

Warning: This Docker image is no longer receiving updates!
You should switch to the Docker images on Docker Hub at:
https://hub.docker.com/u/certbot

The official Docker images come with arm flavors, which you could use instead, e.g.:

sudo docker run -it --rm -p 81:8321 --name certbot \
-v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
certbot/certbot:arm32v6-v1.15.0 certonly --standalone --standalone-supported-challenges http-01 \
--email myemail@email.com -d grembeirn.duckdns.org

That won't solve your port 80 problem, though.

For DuckDNS I suggest trying this.

3 Likes

There is indeed such a plugin

Tried to get this to work yesterday, to no avail. Will try again later this week. But Certbot installation and documentation is a mess. Snap, source, apt/dpkg, pip in the end none of them work out for various reasons. Source installation is broken, apt/dpkg is outdated, snap installation doesn't recognise the plugin, ...

Net very reassuring.

I'll might end up trying the acme alternative, I guess.

To be continued.

If you recall what specific issues you ran into here (these instructions), we'd be very grateful if you could share those issues with us.

Yes, unfortunately due to the way snap confinement works, the plugin needs to be a snap as well. If it's not available as a snap, it won't be visible. All of the official ones are available, but the third-party situation is not as good. I've opened an issue to get this more prominently documented in the instructions. Sorry!

1 Like

Finally managed to get things to work using pip for certbot and plugin. Was able to generate keys for my domain. Now getting an SSL_ERROR_RX_RECORD_TOO_LONG when using https in the browser. Up to the next error :slight_smile:

That port

is a http port, not a https port. Use http with that port, you will see content.

Yeah, I know. Trying to get it to use HTTPS, which is down to server side configuration on my raspberry pi HomeAssistant.
I've managed to create the DNS and get the certificates. Now trying to get HA to switch to HTTPS instead of HTTP. This is off-topic and no longer a question for this forum, I guess.

1 Like

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