Solutions to multiple issues with SSL certificates

[jaklan]

Model: RT-AC86U
Firmware Version: 386.1_beta2

Hi all, I was recently playing with SSL certificates on my router and discover a few things which imho can be helpful to solve problems with SSL certificates. Probably everything below was already mentioned somewhere on the forum, but when I was looking for solutions to my problems I had to read multiple threads and look for individual helpful comments, so I thought putting all of that into one place can be a good idea. Originally I posted these notes on the Asuswrt-Merlin's GitHub.

Generating a new self-signed cert
In WAN - DDNS menu, If you select HTTPS/SSL Certificate as None and Generate a new certificate as Yes then after applying - nothing changes, you still get the old certificate. The reason is /jffs/cert.tgz archive file, which stores 2 files within etc folder: cert.pem and key.pem. If the file exists, then new cert is not generated.

Solution? Ssh into your router and run rm /jffs/cert.tgz before generating a new cert. Now, when applying the above, a new /jffs/cert.tgz file would be created and cert files in /tmp/etc - successfuly replaced.

@RMerlin: my opinion - removing the old file should be just done under-the-hood.

Importing your own cert
In WAN - DDNS menu, If you select Import Your Own Certificate then after uploading files and applying - it works (even if you get No certificate found status). What is interesting here - the uploaded files are stored in /jffs/.cert/ directory, but /jffs/cert.tgz is not modified - it still stores the old cert files. I expected it can be a problem after reboot, but... it isn't, the cert moved to /tmp/etc/ is still the new one. Tbh that's quite surprising to me, I need to investigate it more, but well - the most important part is "it works".

@RMerlin: however it works, maybe it's a good idea to overwrite existing /jffs/cert.tgz anyway to have a repeatable flow?

Generating a certificate from Let's Encrypt (for a custom DDNS)
In WAN - DDNS menu, If you select Free Certificate from Let's Encrypt then after applying - nothing changes. It doesn't matter if you have /jffs/cert.tgz or any files in /jffs/.cert/ - it just doesn't work. If you look at logs, you can see such a line: Dec 24 02:53:29 rc_service: httpd 7936:notify_rc restart_ddns_le;restart_ftpd, but restart_ddns_le seems not to do anything interesting.

But... when you ssh into your router and run service restart_letsencrypt... magic happens and the process of ordering the cert starts - you can track it in System Log -> General Log. The domain used is ofc the one specified in the field Host Name. After all, you can cd /jffs/.le and you will see a new folder named as your domain (e.g. subdomain.domain.com).

However, we are only halfway there - the cert is not working yet. But let's do some experiment - we would get the freshly generated key and cert and pack it into /jffs/cert.tgz:

1. If we look at /jffs/.le/subdomain.domain.com, there are 2 especially interesting files for us: subdomain.domain.com.key and fullchain.pem.
2. Let's create a new /jffs/cert.tgz archive file:
   

   cd /jffs/.le/subdomain.domain.com && mkdir etc
   cp subdomain.domain.com.key etc/key.pem && cp fullchain.pem etc/cert.pem
   cd tar -czf /jffs/cert.tgz etc/key.pem etc/cert.pem

3. Let's reboot: reboot
4. Voila, it works!

What next? The above doesn't answer if the cert is automatically renewed after 3 months, and even if yes - if it's moved to /tmp/etc/ automatically. But if we you know the mechanism, you can automate it on your own or... @RMerlin - again, maybe it can be automated under-the-hood, when applying Let's Encrypt cert in GUI?

PS I have tested the above for a custom domain, don't know if there are any differences if you want to generate a cert for a default *.asuscomm.com domain.

 

[MattM]

Hi all, I was recently playing with SSL certificates on my router and discover a few things which imho can be helpful to solve problems with SSL certificates. Probably everything below was already mentioned somewhere on the forum, but when I was looking for solutions to my problems I had to read multiple threads and look for individual helpful comments, so I thought putting all of that into one place can be a good idea. Originally I posted these notes on the Asuswrt-Merlin's GitHub.

Generating a new self-signed cert
In WAN - DDNS menu, If you select HTTPS/SSL Certificate as None and Generate a new certificate as Yes then after applying - nothing changes, you still get the old certificate. The reason is /jffs/cert.tgz archive file, which stores 2 files within etc folder: cert.pem and key.pem. If the file exists, then new cert is not generated.

Solution? Ssh into your router and run rm /jffs/cert.tgz before generating a new cert. Now, when applying the above, a new /jffs/cert.tgz file would be created and cert files in /tmp/etc - successfuly replaced.

@RMerlin: my opinion - removing the old file should be just done under-the-hood.

Importing your own cert
In WAN - DDNS menu, If you select Import Your Own Certificate then after uploading files and applying - it works (even if you get No certificate found status). What is interesting here - the uploaded files are stored in /jffs/.cert/ directory, but /jffs/cert.tgz is not modified - it still stores the old cert files. I expected it can be a problem after reboot, but... it isn't, the cert moved to /tmp/etc/ is still the new one. Tbh that's quite surprising to me, I need to investigate it more, but well - the most important part is "it works".

@RMerlin: however it works, maybe it's a good idea to overwrite existing /jffs/cert.tgz anyway to have a repeatable flow?

Generating a certificate from Let's Encrypt (for a custom DDNS)
In WAN - DDNS menu, If you select Free Certificate from Let's Encrypt then after applying - nothing changes. It doesn't matter if you have /jffs/cert.tgz or any files in /jffs/.cert/ - it just doesn't work. If you look at logs, you can see such a line: Dec 24 02:53:29 rc_service: httpd 7936:notify_rc restart_ddns_le;restart_ftpd, but restart_ddns_le seems not to do anything interesting.

But... when you ssh into your router and run service restart_letsencrypt... magic happens and the process of ordering the cert starts - you can track it in System Log -> General Log. The domain used is ofc the one specified in the field Host Name. After all, you can cd /jffs/.le and you will see a new folder named as your domain (e.g. subdomain.domain.com).

However, we are only halfway there - the cert is not working yet. But let's do some experiment - we would get the freshly generated key and cert and pack it into /jffs/cert.tgz:

1. If we look at /jffs/.le/subdomain.domain.com, there are 2 especially interesting files for us: subdomain.domain.com.key and fullchain.pem.
2. Let's create a new /jffs/cert.tgz archive file:
   

   cd /jffs/.le/subdomain.domain.com && mkdir etc
   cp subdomain.domain.com.key etc/key.pem && cp fullchain.pem etc/cert.pem
   cd tar -czf /jffs/cert.tgz etc/key.pem etc/cert.pem

3. Let's reboot: reboot
4. Voila, it works!

What next? The above doesn't answer if the cert is automatically renewed after 3 months, and even if yes - if it's moved to /tmp/etc/ automatically. But if we you know the mechanism, you can automate it on your own or... @RMerlin - again, maybe it can be automated under-the-hood, when applying Let's Encrypt cert in GUI?

PS I have tested the above for a custom domain, don't know if there are any differences if you want to generate a cert for a default *.asuscomm.com domain.

Thank you. I used your custom DDNS "tar" repackaging solution with Let'sEncrypt and it worked as suggested (although I had to first wait for 7 days as I had previously used all of the allocated attempts with Let's encrypt...) . I am wondering if the wildcard "*" character for domain *and* subdomains would work with Lets encrypt if the Host name was named as "*.domain.com" as opposed to "domain.com". Not entirely sure if this is the case...

 

[MattM]

Came across this thread: https://www.snbforums.com/threads/wildcard-cert-for-ddns-lets-encrypt.63719/
which suggests that the current closed-source of Let's encrypt will not work with wildcard "*" character in the DDNS Hostname and with Let'sEncrypt to generate a single SSL certification for all domain and subdomains

However, member "Dabombber" appears to have a workaround.

Gonna try that.