How to install custom SSL certificates on an ASUS RT-N66U running asuswrt-merlin

gistfile1.txt

###########################################
# IMPORTANT NOTE:
#
# As of asuswrt-merlin 380.67 Beta, you
# can now configure SSL certificates from
# the Webui, making these instructions
# unnecessary.
###########################################



# First, enable SSH in the Administration->System tab.
# Then log in to the device.

# Verify that https_crt_save is off
admin@RT-N66U:/tmp/home/root# nvram get https_crt_save
0

# Enable https_crt_save and verify that it was set correctly
admin@RT-N66U:/tmp/home/root# nvram set https_crt_save=1
admin@RT-N66U:/tmp/home/root# nvram get https_crt_save
1

# Write your custom key and certificate to the ephemeral file system.
# Note that these files will not be preserved on restart.
admin@RT-N66U:/tmp/home/root# cat >/etc/key.pem
# paste in key
admin@RT-N66U:/tmp/home/root# cat >/etc/cert.pem
# paste in cert

# Verify https_crt_file is empty
admin@RT-N66U:/tmp/home/root# nvram get https_crt_file
admin@RT-N66U:/tmp/home/root#

# Restart httpd. When httpd starts up with https_crt_save enabled, it does the
# following: If /etc/cert.pem and /etc/key.pem exist, it tars them together and
# saves them in https_crt_file.  If they do not exist (this would be the case
# on reboot) and https_crt_file exists, httpd will extract the contents of
# https_crt_file. You can see how this works in the start_ssl function here:
# https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/httpd/httpd.c
admin@RT-N66U:/tmp/home/root# service restart_httpd

# Ensure https_crt_file is now full
admin@RT-N66U:/tmp/home/root# nvram get https_crt_file
# ...snip...

# Reboot AP to make sure cert is put back on boot
admin@RT-N66U:/tmp/home/root# reboot

Maybe extract and retain the other files. The archive looks like this for me, which suggests in december I replaced the key and crt, but kept the rest. Perhaps if other files are missing it regenerates / restores it. I should have kept better notes...

 tar tzvf cert.tgz
-rw-rw-rw- 0/0      1517 2018-05-05 01:05:31 etc/cacert.pem
-rw------- 0/0      1679 2018-05-05 01:05:31 etc/cakey.pem
-rw-rw-rw- 0/0      1838 2023-12-19 22:53:50 etc/cert.pem
-rw------- 0/0      1704 2023-12-19 22:53:51 etc/key.pem
-rw-rw-rw- 0/0      1517 2018-05-05 01:05:31 etc/cacert_gen.pem
-rw------- 0/0      1679 2018-05-05 01:05:31 etc/cakey_gen.pem
-rw-rw-rw- 0/0      1838 2018-05-05 01:05:25 etc/cert_gen.pem
-rw------- 0/0      1675 2018-05-05 01:05:25 etc/key_gen.pem

Yep, that was the missing piece of the puzzle.

Extracting the existing /jffs/cert.tgz into a temp subdir, overwriting etc/key.pem and etc/cert.pem and recreating /jffs/cert.tgz then running nvram set https_crt_save=1 and service restart_httpd seems to do the trick.

Finally !! Thanks for your help !

Yep, that was the missing piece of the puzzle.

Extracting the existing /jffs/cert.tgz into a temp subdir, overwriting etc/key.pem and etc/cert.pem and recreating /jffs/cert.tgz then running nvram set https_crt_save=1 and service restart_httpd seems to do the trick.

Finally !! Thanks for your help !

I tryed exactly this and checked the md5 sum:
Before copy cert.tgz to /jffs/cert.tgz md5 was: ef7ba5b1ec34074a56c1349653860d82
after copy: 899f0ec767378c8e5a84079d4e6315d3 /jffs/cert.tgz
then I ran following commands:

nvram set https_crt_save=1
service restart_httpd

after last command, the md5 was ef7ba5b1ec34074a56c1349653860d82 (as initial).
I'm using: 3.0.0.4.388_24328-g1e6e634
any idea?

after last command, the md5 was ef7ba5b1ec34074a56c1349653860d82 (as initial). I'm using: 3.0.0.4.388_24328-g1e6e634 any idea?

Same here. I am happy for everyone who managed to upload and activate their own certificate, but lost hope for myself.

I am using firmware 3004.388.9 and I'm having the same issue.

My sys log says this after i uploaded my own certificates:

  Apr 26 18:58:45 httpd: Can't get basic constrain from /jffs/.cert/cert.pem
  Apr 26 18:58:45 httpd: Delete uploaded certificate
  Apr 26 18:58:48 admin: Waiting 5 seconds for VPN...

and ChatGPT says this:

  this exact error:
  
  httpd: Can't get basic constrain from /jffs/.cert/cert.pem
  httpd: Delete uploaded certificate

  means:
  your uploaded SSL certificate is being rejected by the Asuswrt-Merlin firmware because it doesn’t contain a required X.509 extension called the Basic Constraints field.
  


  Specifically, Merlin expects certificates to include:
  
  ✅ X509v3 Basic Constraints
  
  ✅ X509v3 Subject Key Identifier
  
  ✅ X509v3 Authority Key Identifier
  
  If these aren't present exactly right, httpd (the web interface server) auto-deletes your uploaded cert.
  
  ✍ Why this happens:
  Since 2024 and even stronger with firmware builds 3004.388.6 → 3004.388.9,
  Merlin strictly enforces proper X.509 standards.
  They're trying to block bad SSL setups that could crash or expose the router.
  
  Old simple OpenSSL certs (without these extensions) get rejected now.
  
  🛠 How you fix it:
  You need to regenerate your certs with an openssl.cnf that includes:
  
  bash
  Copy
  Edit
  basicConstraints = CA:FALSE
  subjectKeyIdentifier = hash
  authorityKeyIdentifier = keyid,issuer
  ✅ This will make the router happy.
  ✅ It will keep your Root CA as is, no need to redo that.
  ✅ Only the server certs (e.g., for rt.datanovaconsulting.com) need updating.

I hope this clears things up for everyone concerning their custom certificates issues!!!

So my CA is using ECDSA with prime256v1. I'm guessing that's my issue here? I have an Asus ROG router and it just reverts back to auto when I upload my key and cert.

✅ X509v3 Authority Key Identifier
This was very helpful - thank you very much!

Root cause: missing Basic Constraints in the server cert (ASUS httpd requirement)

If you’re seeing Merlin fall back to the default RT-AX86U-XXXX Server Certificate even though your custom cert uploads successfully, the issue is not Merlin, not NVRAM, and not cert.tgz structure.

The issue is the X.509 extensions.

ASUS’s embedded httpd strictly requires the server certificate to explicitly contain:

X509v3 Basic Constraints: 
    CA:FALSE

If this extension is missing or not parsable, httpd will log something like:

httpd: Can't get basic constrain from /jffs/.cert/cert.pem
httpd: Delete uploaded certificate

Then silently reverts to the auto-generated ASUS certificate.

Cause of mkcert failure (Theory)

mkcert generates valid browser certificates, but some server certificates don't include an explicit basicConstraints = CA:FALSE entry in a format ASUS’s stripped-down OpenSSL parser accepts.

Fix: generate the router cert with OpenSSL & explicit extensions

Use OpenSSL directly for the router cert and explicitly declare Basic Constraints.

Example router-openssl.conf:

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
CN = router.lan

[ req_ext ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = router.lan
IP.1  = 192.168.1.1

Generate and sign with your local CA (mkcert’s CA works fine):

openssl genrsa -out router-key.pem 2048
openssl req -new -key router-key.pem -out router.csr -config router-openssl.cnf

openssl x509 -req \
  -in router.csr \
  -CA rootCA.pem \
  -CAkey rootCA-key.pem \
  -CAcreateserial \
  -out router.pem \
  -days 3650 \
  -sha256 \
  -extensions req_ext \
  -extfile router-openssl.cnf

You can verify this by using:

openssl x509 -in router.pem -noout -text | grep -A4 "Basic Constraints"

Expected Output:

X509v3 Basic Constraints:
    CA:FALSE

Certificate & key requirements

Requirement	Source
Certificate must be PEM	Implicitly supported by ASUS documentation
Must be RSA (not ECDSA)	Common community reports (e.g., GitHub, SNBForums)
Subject Alternative Name (SAN) required	Older guides and community usage assume SAN for hostname matching
Basic Constraints: CA:FALSE	Supported by community discussions and httpd rejection logs
X509v3 Subject Key Identifier (SKI) & Authority Key Identifier (AKI)	Explicitly mentioned by commenters in Merlin-related discussions
Correct tar layout (/jffs/cert.tgz)	Part of documented ASUSWRT-Merlin workflow
NVRAM flags (https_crt_save=1)	Known ASUSWRT-Merlin requirement

Requirements are not Merlin-specific and are enforced by ASUS’s embedded httpd and OpenSSL build.
Merlin simply exposes the failure logs and allows persistence of custom certificates, which makes the issue debuggable.

Summary

• Not a Merlin bug
• Not an NVRAM or cert.tgz issue
• ASUS httpd enforces strict X.509 parsing
• Missing or malformed Basic Constraints causes silent cert rejection
• OpenSSL with explicit CA:FALSE resolves the issue permanently