"Only RSA or EC key is supported" error on Tomato router os

[Enver-Yilmaz]

Steps to reproduce

Hi,

I try to use acme.sh on my Asus RT-AC68U router. I install Tomato Shibby based os on this router (advancedtomato.com). My plan is use build in nginx as SSL offloading reverse proxy and use le certificates for ssl. The router has a writeable partition mounted at /jffs path so I install acme.sh with the following method;

./acme.sh --install --home /jffs/acme --config-home /jffs/acme/data --certhome /jffs/acme/certs --accountemail "my@email.address"

I create /jffs/acme/dnsapi folder and copy dns_cloudns.sh in it and make script executeable

I modified /etc/profile and add . "/jffs/acme/acme.sh.env" in it

I modified /jffs/acme/acme.sh.env and add following lines with my auth id and password
export CLOUDNS_AUTH_ID=XXXXX
export CLOUDNS_AUTH_PASSWORD="YYYYYYYYY"

I observe LE_WORKING_DIR, LE_CONFIG_DIR, CLOUDNS_AUTH_ID and CLOUDNS_AUTH_PASSWORD environment variables exported successfully between reboots.

I issue the following command to obtain certificate;
acme.sh --issue --dns dns_cloudns -d esoft.com.tr -d *.esoft.com.tr --debug 2

I get this response:
"Only RSA or EC key is supported."

I search the key files and found newly created directory with an empty account.key file at /jffs/acme/data/ca/acme-v02.api.letsencrypt.org/

I can't figure out if socat is a dependency for this process which is not available. I deliberately want to use dns challenge to simplify setup on host.

l really appreciate any help.
Enver

Debug log

Wed May 2 11:39:09 UTC 2018] Using config home:/jffs/acme/data
[Wed May 2 11:39:09 UTC 2018] LE_WORKING_DIR='/jffs/acme'
/~https://github.com/Neilpang/acme.sh
v2.7.9
[Wed May 2 11:39:09 UTC 2018] _main_domain='esoft.com.tr'
[Wed May 2 11:39:09 UTC 2018] _alt_domains='.esoft.com.tr'
[Wed May 2 11:39:09 UTC 2018] Using config home:/jffs/acme/data
[Wed May 2 11:39:09 UTC 2018] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Wed May 2 11:39:09 UTC 2018] _ACME_SERVER_HOST='acme-v02.api.letsencrypt.org'
[Wed May 2 11:39:10 UTC 2018] DOMAIN_PATH='/jffs/acme/certs/esoft.com.tr'
[Wed May 2 11:39:10 UTC 2018] 'dns_cloudns' does not contain 'dns'
[Wed May 2 11:39:10 UTC 2018] Using ACME_DIRECTORY: https://acme-v02.api.letsencrypt.org/directory
[Wed May 2 11:39:10 UTC 2018] _init api for server: https://acme-v02.api.letsencrypt.org/directory
[Wed May 2 11:39:10 UTC 2018] GET
[Wed May 2 11:39:10 UTC 2018] url='https://acme-v02.api.letsencrypt.org/directory'
[Wed May 2 11:39:10 UTC 2018] timeout=
[Wed May 2 11:39:10 UTC 2018] _CURL='curl -L --silent --dump-header /jffs/acme/data/http.header --trace-ascii /tmp/acme.shwefADf24sf.1525250350.tmp -g '
[Wed May 2 11:39:11 UTC 2018] ret='0'
[Wed May 2 11:39:11 UTC 2018] response='{
"BdKr94n900U": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
"keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
"meta": {
"caaIdentities": [
"letsencrypt.org"
],
"termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
"website": "https://letsencrypt.org"
},
"newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
"newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
"newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
"revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}'
[Wed May 2 11:39:12 UTC 2018] ACME_KEY_CHANGE='https://acme-v02.api.letsencrypt.org/acme/key-change'
[Wed May 2 11:39:12 UTC 2018] ACME_NEW_AUTHZ
[Wed May 2 11:39:12 UTC 2018] ACME_NEW_ORDER='https://acme-v02.api.letsencrypt.org/acme/new-order'
[Wed May 2 11:39:12 UTC 2018] ACME_NEW_ACCOUNT='https://acme-v02.api.letsencrypt.org/acme/new-acct'
[Wed May 2 11:39:12 UTC 2018] ACME_REVOKE_CERT='https://acme-v02.api.letsencrypt.org/acme/revoke-cert'
[Wed May 2 11:39:12 UTC 2018] ACME_AGREEMENT='https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf'
[Wed May 2 11:39:12 UTC 2018] ACME_NEW_NONCE='https://acme-v02.api.letsencrypt.org/acme/new-nonce'
[Wed May 2 11:39:12 UTC 2018] ACME_VERSION='2'
[Wed May 2 11:39:13 UTC 2018] _on_before_issue
[Wed May 2 11:39:13 UTC 2018] _chk_main_domain='esoft.com.tr'
[Wed May 2 11:39:13 UTC 2018] _chk_alt_domains='.esoft.com.tr'
[Wed May 2 11:39:13 UTC 2018] 'dns_cloudns' does not contain 'no'
[Wed May 2 11:39:13 UTC 2018] Le_LocalAddress
[Wed May 2 11:39:13 UTC 2018] d='esoft.com.tr'
[Wed May 2 11:39:13 UTC 2018] Check for domain='esoft.com.tr'
[Wed May 2 11:39:13 UTC 2018] _currentRoot='dns_cloudns'
[Wed May 2 11:39:13 UTC 2018] d='.esoft.com.tr'
[Wed May 2 11:39:13 UTC 2018] Check for domain='.esoft.com.tr'
[Wed May 2 11:39:14 UTC 2018] _currentRoot='dns_cloudns'
[Wed May 2 11:39:14 UTC 2018] d
[Wed May 2 11:39:14 UTC 2018] 'dns_cloudns' does not contain 'apache'
[Wed May 2 11:39:14 UTC 2018] config file is empty, can not read CA_KEY_HASH
[Wed May 2 11:39:14 UTC 2018] _saved_account_key_hash
[Wed May 2 11:39:14 UTC 2018] Using config home:/jffs/acme/data
[Wed May 2 11:39:14 UTC 2018] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Wed May 2 11:39:14 UTC 2018] _ACME_SERVER_HOST='acme-v02.api.letsencrypt.org'
[Wed May 2 11:39:14 UTC 2018] _init api for server: https://acme-v02.api.letsencrypt.org/directory
[Wed May 2 11:39:14 UTC 2018] Only RSA or EC key is supported.
[Wed May 2 11:39:15 UTC 2018] on_issue_err
[Wed May 2 11:39:15 UTC 2018] Please add '--debug' or '--log' to check more details.
[Wed May 2 11:39:15 UTC 2018] See: /~https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh
[Wed May 2 11:39:15 UTC 2018] chk_vlist
[Wed May 2 11:39:15 UTC 2018] socat doesn't exists.
[Wed May 2 11:39:15 UTC 2018] Diagnosis versions:
openssl:openssl
OpenSSL 1.0.2k 26 Jan 2017
apache:
apache doesn't exists.
nginx:
nginx version: nginx/1.10.3
built with OpenSSL 1.0.2k 26 Jan 2017
TLS SNI support enabled
configure arguments: --crossbuild=Linux::arm --prefix=/usr --sbin-path=/usr/sbin --conf-path=/etc/nginx/nginx.conf --error-log-path=/tmp/var/log/nginx/error.log --http-log-path=/tmp/var/log/nginx/access.log --pid-path=/tmp/var/run/nginx.pid --lock-path=/tmp/var/run/nginx.lock.accept --http-client-body-temp-path=/tmp/var/lib/nginx/client --http-fastcgi-temp-path=/tmp/var/lib/nginx/fastcgi --with-http_flv_module --with-http_ssl_module --with-http_gzip_static_module --http-uwsgi-temp-path=/tmp/var/lib/nginx/uwsgi --http-scgi-temp-path=/tmp/var/lib/nginx/scgi --http-proxy-temp-path=/tmp/var/lib/nginx/proxy --with-cc=arm-brcm-linux-uclibcgnueabi-gcc --with-ld-opt=' -L /home/jacky/advancedtomato-arm/release/src-rt-6.x.4708/router/pcre/.libs -L /home/jacky/advancedtomato-arm/release/src-rt-6.x.4708/router/zlib -L /home/jacky/advancedtomato-arm/release/src-rt-6.x.4708/router/openssl' --with-cc-opt='-DLINUX26 -DCONFIG_BCMWL5 -DCONFIG_BCMWL6 -DCONFIG_BCMWL6A -DPART_JFFS2_GAP=0UL -pipe -fno-strict-aliasing -DBCMWPA2 -DBCMARM -marm -DTCONFIG_NVRAM_64K -DLINUX_KERNEL_VERSION=132644 -DBCMWPA2 -DBCMQOS -DBCM_DCS -DEXT_ACS -DD11AC_IOTYPES -DNAS_GTK_PER_STA -DPHYMON -DPROXYARP -DTRAFFIC_MGMT -DTRAFFIC_MGMT_RSSI_POLICY -DLINUX26 -DCONFIG_BCMWL5 -DCONFIG_BCMWL6 -DCONFIG_BCMWL6A -DPART_JFFS2_GAP=0UL -pipe -fno-strict-aliasing -DBCMWPA2 -DBCMARM -marm -DTCONFIG_NVRAM_64K -DLINUX_KERNEL_VERSION=132644 -O2 -D__CONFIG_EMF -I /home/jacky/advancedtomato-arm/release/src-rt-6.x.4708/router/openssl/include -I /home/jacky/advancedtomato-arm/release/src-rt-6.x.4708/router/openssl/include/openssl -I /home/jacky/advancedtomato-arm/release/src-rt-6.x.4708/router/pcre -I /home/jacky/advancedtomato-arm/release/src-rt-6.x.4708/router/zlib'
socat:

[Enver-Yilmaz]

I reinstall acmes.sh with my own key file;

./acme.sh --install  \
--home /jffs/acme \
--config-home /jffs/acme/data \
--certhome  /jffs/acme/certs \
--accountemail  "admin@esoft.com.tr" \
--accountkey  /jffs/acme/data/account.key \
--force

after issue command, I saw openssl errors;

openssl:Error: 'base64' is an invalid command.

Standard commands
enc            req            rsa            s_client       speed          
version        x509           

Cipher commands (see the `enc' command for more details)
aes-128-cbc    aes-128-ecb    aes-192-cbc    aes-192-ecb    aes-256-cbc    
aes-256-ecb    bf-cbc         bf-ecb 

I guess openssl on this platform is somehow limited. Is there any suggestion or I should give up to use acme.sh here?

[Neilpang]

It seems that your openssl is missing some functionality.

[mrand]

@Enver-Yilmaz There is a newer version of Tomato for some routers that might have a newer version of openSSL (main one is called Fresh Tomato).

[Martinique]

I managed to get acme.sh to install on Tomato (needs some tweaking, --force and Admin>Scheduler instead of crontab, at least), but now I'm facing this same issue. Tomato's cut-down openssl executable doesn't recognize the 'ecparam' command, which is probably why it produces an empty account.key, leading to this error.

I worked around that by creating account.key on another computer using RSA (openssl genrsa 2048), but Tomato's openssl also lacks base64 needed elsewhere: "openssl:Error: 'base64' is an invalid command."

@mrand Do you know if FreshTomato or some other fork has a more capable openssl? It's easy to check with "openssl help" and seeing if "Standard commands" list has 'base64'.

Edit: Interestingly Tomato's openssl CAN encode/decode base64, but the syntax is "openssl enc -base64" instead of acme.sh's "openssl base64". Perhaps I can edit acme.sh slightly to make this work...

Edit 2: The above change indeed got base64 working, but now openssl is complaining about 'dgst', so back to my original question.

[Neilpang]

Edit: Interestingly Tomato's openssl CAN encode/decode base64, but the syntax is "openssl enc -base64" instead of acme.sh's "openssl base64". Perhaps I can edit acme.sh slightly to make this work...

please show me the full command, so that we can support it.

Edit 2: The above change indeed got base64 working, but now openssl is complaining about 'dgst', so back to my original question.

It's used to calculate hash value. see the _digest() function.
If openssl doesn't work, is there any other command tool can do it?
for examepl: sha256sum etc.
If it has, we can implement _digest() function to support it.

Thanks.

[Neilpang]

@Martinique

[Martinique]

@Neilpang Here's how I altered _base64() and _dbase64() to make them compatible:

#Usage: multiline
_base64() {
  [ "" ] #urgly
  if [ "$1" ]; then
    _debug3 "base64 multiline:'$1'"
    ${ACME_OPENSSL_BIN:-openssl} enc -base64 -e
  else
    _debug3 "base64 single line."
    ${ACME_OPENSSL_BIN:-openssl} enc -base64 -e | tr -d '\r\n'
  fi
}

#Usage: multiline
_dbase64() {
  ${ACME_OPENSSL_BIN:-openssl} enc -base64 -d
}

Tomato's openssl doesn't support the -A flag I found in _dbase64(), but AFAIK it's only for encoding and works like the tr command there. According to my tests base64 decoding always ignores line breaks, so I simplified _dbase64().

For digests I only found md5sum on Tomato, but at least the full version I'm running has PHP which could be used as fallback for hashing. I'll get back to this as soon as I find some time to experiment. Tomato's openssl has a bad habit of returning 0 even on failures, so handling those may get a bit complicated.

[Martinique]

I managed to alter _digest() and _hmac() functions to use PHP instead of openssl when available, but _sign() doesn't seem possible with PHP, so I gave up.

I think this issue can be closed, because I can confirm that FreshTomato and probably other new Tomato forks come with a fully capable openssl and thus can run acme.sh as it is (with suitable options, of course).

[mrand]

@Martinique

For anyone that might come along and find this later, could you point to steps for getting it running on FreshTomato?

[Martinique]

@mrand I'm helping a friend setting up FreshTomato to provide a HTTPS layer for his smart home stuff. I'll post info as soon as we confirm they work OK.

[mrand]

@Martinique: Funny, that's what I was going to use it for. But for now I just decided to donate $5 / month to support Home Assistant development, which includes remote access.

[Martinique]

@mrand I'm glad that such paid services exist, but IMHO ultimately we need to build things that benefit everyone. Access between home and phone must never be controlled by tech giants alone. I bet ET would agree.

[Martinique]

IMPORTANT: Consider everything below outdated and see the wiki guide instead.

As requested, I wrote a little guide for using acme.sh with name-based HTTPS reverse proxies in Tomato. I'm pretty sure there's a typo or two somewhere, so let me know if you find one.

Prerequisites

• A router with USB ports running FreshTomato or another recent Tomato fork with a fully featured OpenSSL and web server. A fast CPU is recommended.
• Unless you happen to have a static public IP, you need a dynamic DNS (DDNS) service configured in Tomato. Some DNS services also provide API control, enabling DNS mode for acme.sh. You can point additional regular CNAME records to the DDNS hostname, so not all your hostnames need to be dynamic.
• At least one plain HTTP web service or site running on either a LAN host or Tomato itself. It's a good idea to assign static IP addresses for servers.

Traffic to HTTPS port(s) (the usual 443 or whatever you use) will be forwarded to plain HTTP services on your LAN hosts with Tomato functioning as a reverse proxy. This way you can have multiple (sub)domains in a single public port pointed to several LAN servers with Tomato handling all the HTTPS stuff, which is not possible with simple port forwarding. I'll provide a configuration example.

If you're going to issue using webroot mode, Tomato's web server must be running in port 80, so make sure your operator doesn't block that port and that the web admin service is not using the same port.

Standalone modes won't work, as there's no socat in Tomato (without entware).

Installing

Format a USB HDD or flash drive as ext4 (or ext2 if you don't need journaling) and name the partition as you wish. For this example I named my partition "flash", so Tomato auto-mounts it to /tmp/mnt/flash.

You could use Tomato's JFFS partition instead of an external drive, but firmware upgrades need JFFS disabled, so it's rather inconvenient.

SSH to your Tomato and paste these commands to download and extract acme.sh:

cd /tmp/mnt/flash
wget /~https://github.com/Neilpang/acme.sh/archive/master.zip
unzip master.zip
rm master.zip
cd acme.sh-master
chmod +x acme.sh

You're now ready to install. Change the email address before running this install command:

./acme.sh --install --nocron --home /tmp/mnt/flash/acme.sh \
--accountemail "your.email@example.com" --useragent "Tomato router"

Finally remove the installer directory: cd .. && rm -Rf acme.sh-master

The installer wrote a line to the .profile file in the root user's home directory. Tomato keeps this directory on a RAM disk, so you need to make this permanent by adding this command to Administration→Scripts→Init:

echo '. "/tmp/mnt/flash/acme.sh/acme.sh.env"' >> /tmp/home/root/.profile

Close the current SSH session and start a new one to activate the change.

Now go to Administration→Scheduler. Scheduled commands ignore the .profile file, so you need to provide the full path to acme.sh and set the directory options. Put this line in one of the custom command fields and set it to run daily, preferrably at a time when there's least traffic:

/tmp/mnt/flash/acme.sh/acme.sh --cron --home /tmp/mnt/flash/acme.sh --config-home /tmp/mnt/flash/acme.sh/conf

Configuring Tomato's web server

If you'll only use DNS mode, you don't need to set the port and path; they're for acme.sh's webroot mode.

Go to Web Server→Basic Settings and set it up like this:

• Check Enable Server on Start and Allow Remote Access
• Run As: Nobody (running as root is generally a bad idea)
• Web Server Port: 80
• Server Root Path: /tmp/mnt/flash/www

Save the settings and then create the directory for webroot challenges:

mkdir -p /tmp/mnt/flash/www/.well-known/acme-challenge

Issuing certificates

There's nothing Tomato-specific about this, except that you can only use webroot or DNS mode.

Webroot mode:

acme.sh --issue -d tomato.example.com -d www.tomato.example.com -w /tmp/mnt/flash/www

DNS mode (see the guide):

acme.sh --issue -d tomato.example.com -d www.tomato.example.com --dns dns_xxxx

Installing certificates

Create a directory for your new certificate and install it there:

mkdir -p /tmp/mnt/flash/cert/tomato.example.com

acme.sh --install-cert -d tomato.example.com \
--fullchain-file /tmp/mnt/flash/cert/tomato.example.com/fullchain.pem \
--key-file /tmp/mnt/flash/cert/tomato.example.com/key.pem \
--reloadcmd "service enginex restart"

Note that Tomato has a funny typo, internally calling nginx "enginex".

Since nginx runs as user "nobody" you need to make the chain and key files readable by it. Change their owner group to nobody and allow group read permissions:

chown root:nobody /tmp/mnt/flash/cert/tomato.example.com/*
chmod 0640 /tmp/mnt/flash/cert/tomato.example.com/*

Tomato is a single-user system, so you don't need to worry about file permissions much. Just don't put any vulnerable PHP code on the web server; leaking private keys and altering NVRAM would be pretty bad.

Adding a reverse proxy

Modify the below example to match your new hostname(s), certificate path and LAN server IP and port (on the proxy_pass line) and add it to the HTTP Section field in Web Server→Advanced Settings. This is a minimalist reverse proxy example, so read some guides to learn about more options, especially security-related.

If the server is Tomato itself, set proxy_pass to http://127.0.0.1:80 (match the port number with web server setting).

You can add as many proxy server configurations as you wish, but note that they take up precious NVRAM, unless you move the whole nginx configuration to a file, disabling GUI settings. In many cases you can leave out the proxy_set_header lines, as they only provide connection info for logging etc.

server {
  listen 443 ssl;
  server_name tomato.example.com www.tomato.example.com;
  ssl_certificate /tmp/mnt/flash/cert/tomato.example.com/fullchain.pem;
  ssl_certificate_key /tmp/mnt/flash/cert/tomato.example.com/key.pem;
  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://192.168.0.3:8080;
    proxy_redirect off;
  }
}

Save the settings and wait for Tomato to restart nginx. You should now be able to access the LAN HTTP server from outside through https://tomato.example.com/

Notes

• While testing this stuff I came across some situations where Tomato's RAM disk ran out of space, causing failures writing configuration files. I'm not sure what causes it, but you can check with df -h /tmp, and a reboot fixes it.
• Not all HTTP services are proxy-compatible. For example, absolute URLs can be troublesome, although you can fix them with http_sub filters.
• This should be obvious, but people can be surprisingly dumb: Don't create public proxy connections to LAN devices/services without proper password protection.

[Neilpang]

@Martinique Please add this to the wiki page.
I just invited you to edit the wiki page.

[Martinique]

@Neilpang Thanks, but before that I'd like to see others test this to ensure that everything works as described.

[Martinique]

@Neilpang Several people with various routers and Tomato versions have confirmed that my solution works, so I'll soon add the wiki page and edit my guide in this thread to point people to the wiki guide.

[Neilpang]

@Martinique good

[richieboymx]

Hello @Martinique... following your instructions, I'm stuck at issuing the certificate. This is the debug (I'm on FreshTomato 2020.2):

[Sun May 10 07:10:25 UTC 2020] Running cmd: issue
[Sun May 10 07:10:25 UTC 2020] _main_domain='real.domain.here'
[Sun May 10 07:10:26 UTC 2020] _alt_domains='real.domain.here'
[Sun May 10 07:10:26 UTC 2020] Using config home:/tmp/mnt/sda1/nginx/acme.sh
[Sun May 10 07:10:26 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Sun May 10 07:10:26 UTC 2020] DOMAIN_PATH='/tmp/mnt/sda1/nginx/acme.sh/real.domain.here'
[Sun May 10 07:10:27 UTC 2020] Using ACME_DIRECTORY: https://acme-v02.api.letsencrypt.org/directory
[Sun May 10 07:10:27 UTC 2020] _init api for server: https://acme-v02.api.letsencrypt.org/directory
[Sun May 10 07:10:27 UTC 2020] GET
[Sun May 10 07:10:27 UTC 2020] url='https://acme-v02.api.letsencrypt.org/directory'
[Sun May 10 07:10:27 UTC 2020] timeout=
[Sun May 10 07:10:27 UTC 2020] _CURL='curl -L --silent --dump-header /tmp/mnt/sda1/nginx/acme.sh/http.header  -g '
[Sun May 10 07:10:28 UTC 2020] ret='0'
[Sun May 10 07:10:29 UTC 2020] ACME_KEY_CHANGE='https://acme-v02.api.letsencrypt.org/acme/key-change'
[Sun May 10 07:10:29 UTC 2020] ACME_NEW_AUTHZ
[Sun May 10 07:10:29 UTC 2020] ACME_NEW_ORDER='https://acme-v02.api.letsencrypt.org/acme/new-order'
[Sun May 10 07:10:29 UTC 2020] ACME_NEW_ACCOUNT='https://acme-v02.api.letsencrypt.org/acme/new-acct'
[Sun May 10 07:10:30 UTC 2020] ACME_REVOKE_CERT='https://acme-v02.api.letsencrypt.org/acme/revoke-cert'
[Sun May 10 07:10:30 UTC 2020] ACME_AGREEMENT='https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf'
[Sun May 10 07:10:30 UTC 2020] ACME_NEW_NONCE='https://acme-v02.api.letsencrypt.org/acme/new-nonce'
[Sun May 10 07:10:30 UTC 2020] ACME_VERSION='2'
[Sun May 10 07:10:30 UTC 2020] Le_NextRenewTime
[Sun May 10 07:10:31 UTC 2020] _on_before_issue
[Sun May 10 07:10:31 UTC 2020] _chk_main_domain='real.domain.here'
[Sun May 10 07:10:31 UTC 2020] _chk_alt_domains='real.domain.here'
[Sun May 10 07:10:31 UTC 2020] Le_LocalAddress
[Sun May 10 07:10:32 UTC 2020] d='real.domain.here'
[Sun May 10 07:10:32 UTC 2020] Check for domain='real.domain.here'
[Sun May 10 07:10:32 UTC 2020] _currentRoot='/tmp/mnt/sda1/nginx/www'
[Sun May 10 07:10:32 UTC 2020] d='real.domain.here'
[Sun May 10 07:10:32 UTC 2020] Check for domain='real.domain.here'
[Sun May 10 07:10:32 UTC 2020] _currentRoot='/tmp/mnt/sda1/nginx/www'
[Sun May 10 07:10:32 UTC 2020] d
[Sun May 10 07:10:33 UTC 2020] config file is empty, can not read CA_KEY_HASH
[Sun May 10 07:10:33 UTC 2020] Using config home:/tmp/mnt/sda1/nginx/acme.sh
[Sun May 10 07:10:33 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Sun May 10 07:10:33 UTC 2020] _init api for server: https://acme-v02.api.letsencrypt.org/directory
[Sun May 10 07:10:33 UTC 2020] Use default length 2048
[Sun May 10 07:10:34 UTC 2020] length='2048'
[Sun May 10 07:10:34 UTC 2020] Using config home:/tmp/mnt/sda1/nginx/acme.sh
[Sun May 10 07:10:34 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Sun May 10 07:10:34 UTC 2020] Use length 2048
[Sun May 10 07:10:34 UTC 2020] Using RSA: 2048
[Sun May 10 07:10:34 UTC 2020] error rsa key: 2048
[Sun May 10 07:10:35 UTC 2020] Create account key error.
[Sun May 10 07:10:35 UTC 2020] Create account key error.
[Sun May 10 07:10:35 UTC 2020] _on_issue_err
[Sun May 10 07:10:35 UTC 2020] Please add '--debug' or '--log' to check more details.
[Sun May 10 07:10:35 UTC 2020] See: /~https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
[Sun May 10 07:10:35 UTC 2020] socat doesn't exists.

-- log
[Sun May 10 07:24:29 UTC 2020] Only RSA or EC key is supported. keyfile=/tmp/mnt/sda1/nginx/acme.sh/ca/acme-v02.api.letsencrypt.org/account.key

[Martinique]

Sorry about the long wait, but the pandemic caused such a huge mess that I haven't had time for these router hobbies. I'm just happy to be alive, albeit with some permanent lung damage and perhaps more. Stay safe, everyone!

@richieboymx, I haven't seen such a problem on any of the routers me and others have worked on. socat shouldn't be needed outside standalone mode. @Neilpang, do you know if a recent development has changed this?

[Martinique]

@richieboymx, are you using an AIO (all-in-one) build or a smaller one? Perhaps some limited builds still have limited software.

Looking at the log output it looks like there's a problem with file paths and/or permissions, which could be why the script tries to default to standalone mode.

[richieboymx]

Thank you @Martinique; It was the AIO firmware, but a MIPS based router. I ended up upgrading to an ARM Router with more juice and worked fine after that.

[Martinique]

Thanks for the info, @richieboymx. I'll mention possible issues with MIPS in the wiki article.

[Martinique]

I'm pretty sure this issue can be closed now, @Neilpang. Nobody has reported further problems.