What's new

Importing own certificate broken on 3004.388.6 ?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Mando

Occasional Visitor
Hi,

I upgraded from 3004.388.5 to 3004.388.6 on my AX88U Pro and saw in the changelog there was something about certificates that changed.

So as expected after the upgrade my certificate seemed broken so I decided to just reupload my own certificate files but this does not work. After choosing my own cert & private key, the GUI keeps reverting back to the autogenerated certificate (there's no indication my cert is even saved).

I tried on another AX88U Pro that still has 3004.388.5 & there it works without a hitch. On that one I autogenerated an ASUS cert & then replaced it with my own in a couple of seconds. But on the AX88U Pro with 3004.388.6 it always defaults back to the ASUS cert...

I'm using a p12 certificate where I extract the private key & certificate from to PEM format using OpenSSL (no password on the p12). These 2 files work fine on 3004.388.5 so I don't really think anything is wrong with the way I'm doing it?

After clicking Apply I'm checking /jffs/.cert/ but it appears my certs are not being saved there. Directory remains empty. I have tried using both DDNS enabled or disabled and when enabled I added the "ca-trust-file = /etc/ssl/certs/ca-certificates.crt" setting to my inadyn.conf but nothing seems to help me get my own certificate back to working order.

Also noticed a similar thread here but there the values in the GUI actually updated where for me they do not...

Is there any way around the GUI to import your own certificate like using the CLI?
 
Last edited:
Look at the system log for any error message. Asus now has some stricter validation steps done at the time the certificate is uploaded.
 
Look at the system log for any error message. Asus now has some stricter validation steps done at the time the certificate is uploaded.
"NOTICE" "Delete uploaded certificate"
"NOTICE" "Can't get basic constrain from /jffs/.cert/cert.pem"

Re-issued the certificate from my own CA with Basic Constraints Extension enabled and now it works. Did need a reboot to kick in though, after applying the ASUS cert was still being used by the webserver.

Thanks.
 
Last edited:
I'm having trouble using my own cert as well on 388.6. I upload the key and cert, but as soon as I hit ok in the upload dialog, this appears in the system log:

Code:
Feb 13 02:17:07 httpd: Can't get subject/authority key identifier. ([NULL]/[NULL])
Feb 13 02:17:07 httpd: Delete uploaded certificate

I'm generating the certs with the below script:

Bash:
#!/bin/sh

if [ "$#" -lt 1 ]
then
  echo "Usage: Must supply a domain"
  exit 1
fi

DOMAIN=$1
IP=$2

cd ./hostnames

cat > $DOMAIN.cnf << EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = stateName
localityName = Locality Name (eg, city)
localityName_default = localityName
organizationName = Organization Name (eg, company)
organizationName_default = organizationName
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = organizationalUnitName
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = $DOMAIN
commonName_max = 64
emailAddress = Email Address
emailAddress_default = email@mail.com

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = $DOMAIN
#ALTERNATE NAMES
DNS.2 = $DOMAIN.lan
DNS.3 = *.$DOMAIN.lan
IP.1 = $IP
DNS.4 = localhost
IP.2 = 127.0.0.1
EOF

ROOTPATH="./rootcerts"

openssl genrsa -out $DOMAIN.key 2048

openssl req -new -out $DOMAIN.csr -key $DOMAIN.key -config $DOMAIN.cnf

openssl x509 -req -in $DOMAIN.csr -CA $ROOTPATH/myCA.pem -CAkey $ROOTPATH/myCA.key -CAcreateserial -out $DOMAIN.crt -days 825 -sha256 -extensions v3_req -extfile $DOMAIN.cnf

openssl pkcs12 -export -out $DOMAIN.pfx -inkey $DOMAIN.key -in $DOMAIN.crt
 
A little update. I downgraded to 388.5, installed my custom SSL cert, and then upgraded to 388.6. The DDNS page now looks like below, and the cert works, but you can see that the Root/Intermediate area is blank.

I'm not sure how to get a new cert accepted in 388.6+. Do I have to install my root CA somewhere on the router, maybe? Or maybe there's a way of generating a cert that has the root/intermediate attached?

1707838138685.png
 
Root certificate is optional.
 
If it's optional, why does importing a new certificate fail without it? The uploaded cert gets immediately deleted (per the log above) and an auto-generated one is used.
Is your certificate signed by a known CA? If yes, then you don't need to provide a CA certificate since it's already part of the firmware's CA bundle. That's what I mean by "optional".
 
Hello,

I have a Root CA, an Intermediate CA, and a certificate signed by the Intermediate CA. I bundle the certificates together, and have been using this standard approach successfully on all my servers (Ubiquiti, nginx, previous Asus-Merlin <3004.388.6).

My certificate and private unencrypted key are located in `/jffs/.cert/`, this used to work, but after the upgrade to 3004.388.6, although the web ui shows the certificate, it not used for https. (yes I do `restart_httpd`)

What are precisely the new validation checks? I read above in this thread that Basic Constraints Extension need to be enabled, but it's not clear to me whether this ended up being sufficient to have the router accept my certificate bundle.

Thanks!
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top