Install a custom certificate

ricsvcr · June 1, 2020, 7:08am

Hi there, I downloaded the latest OpenWRT version available (19.07.3) today for my linksys WRT2300ACM. One of the first things I wanted to do was to install a custom self-signed certificate, unfortunately I've been dealing with that for hours and I still can't make it work.

I followed the steps here
https://openwrt.org/docs/guide-user/luci/luci.essentials#installation to install luci-ssl-nginx, and then I also followed the steps here https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings to update the certificate and private key file through LuCI.

I'd like to say that I'm fairly familiar with SSH, TLS/SSL Certificates and Linux, and I do understand the process described in those links, particularly the last one, but having said that I wouldn't call my self an expert since I don't do this everyday and I may be doing something wrong.

I initially tried installing my own self-signed certificate which I generated using openssl on a Linux machine. I also generated and installed a CA certificate for my computer and used that CA to sign the new router certificate, then I copied the router certificate and private key files to /etc/ssl on the router using SFTP (installed previously). Here I started following the steps to select my CRT and KEY files through LuCI (Services > uHTTPd), clicked Save and Apply, Rebooted the router, refreshed the browser but nothing changed, I still see the old certificate on the browser.

I verified the configuration file manually (/etc/config/uhttpd) by SSHing into the router and it looks good, the configuration file shows the correct path for the files.
option cert '/etc/ssl/router.crt'
option key '/etc/ssl/router.key'

I've gone through the same process with some variations, copied the files to /etc, /etc/ssl, /etc/ssl/certs and /etc/ssl/private, every time I make a change I save the files or use "Save and Apply" if I'm in the GUI and restart uhttpd either through to the GUI or with "services uhttpd restart" or even reboot the router if that doesn't work. It doesn't matter what I do, the router won't pick up the new files, it is still serving the original files created during the installation. I even deleted the CRT and KEY files on the router (/etc/uhttpd.crt and /etc/uhttpd.key) and all the files I created, rebooted and the router is still serving the original CRT and KEY files... how is it serving the original files if I deleted them!?

It all makes me believe that the original certificate and key files are cached somewhere. LuCI is correctly updating the configuration file (/etc/config/uhttpd) but that doesn't matter because the router won't pick up the files.

I also cleared the cache in my browser several times, but that didn't make any difference either.

My last test was to follow the steps in the second link above religiously, I only updated the DNS and IP, and that didn't work either.

I'm out of ideas, appreciate any help!

juppin · June 1, 2020, 7:38am

This is the wrong config file for your used nginx webserver!
Nginx currently has no config in /etc/config and has to be configured in /etc/nginx/conf.d/.

For adding a config to /etc/config, there are currently two pull requests that are RFC.

github.com/openwrt/packages

[RFC] nginx-util: use uci for server configuraton

openwrt:master ← peter-stadler:nginx-util

opened 01:52PM - 28 Feb 20 UTC

peter-stadler

+2189 -242

Maintainer: me Compile tested: x86_64, x86_64 qemu, master Run tested: x86_64,… x86_64 qemu, master, running test-nginx-ssl-util-root.sh **tl;dr:** The functions `{add,del}_ssl` modify a server section of the UCI config if there is no `.conf` file with the same name in `/etc/nginx/conf.d/`. Then `init_lan` creates `/var/lib/nginx/uci.conf` files by copying the `/etc/nginx/uci.conf.template` and standard options from the UCI config; additionally the special path `logd` can be used in `{access,error}_log`. The init does not change the configuration beside re-creating self-signed certificates when needed. This is also the only purpose of the new `check_ssl`, which is installed as yearly cron job. **Initialization:** Invoking `nginx-util init_lan` parses the UCI configuration for package `nginx`. It creates a server part in `/var/lib/nginx/uci.conf` for every `section server '$name'` by copying all UCI options but the following: * `option uci_manage_ssl` is skipped. It is set to 'self-signed' by `nginx-util add_ssl $name`, removed by `nginx-util del_ssl $name` and used by `nginx-util check_ssl` (see below). * `logd` as path in `error_log` or `access_log` writes them to STDERR respective STDOUT, which are fowarded by Nginx's init to the log daemon. Specifically: `option error_log 'logd'` becomes `error_log stderr;` and `option access_log 'logd openwrt'` becomes `access_log /proc/self/fd/1 openwrt;` * Other `[option|list] key 'value'` entries just become `key value;` directives. The init calls internally also `check_ssl` for rebuilding self-signed SSL certificates if needed (see below). And it still sets up `/var/lib/nginx/lan{,_ssl}.listen` files as it is doing in the current version (so they stay available). **Defaults:** The package installs the file `/etc/nginx/restrict_locally` containing allow/deny directives for restricting the access to LAN addresses by including it into a server part. This file is included by the default server that listens on all IPs (instead of only the local IPs as it did before, other servers do not need to listen on the local IPs explicitly anymore). The default server is contained (together with a server that redirects inexistent URLs to https in the SSL version) in the UCI configuration file `/etc/config/nginx`. Furthermore, the packages installs a `/etc/nginx/uci.conf.template` containing the current setup and a marker, which will be replaced by the created UCI servers when calling `init_lan`. **Other:** If there is a file named `/etc/nginx/conf.d/$name.conf` the functions `init_lan`, `add_ssl $name` and `del_ssl $name` will use that file instead of a UCI server section with the same $name (as it is doing in the current version). Else if there is only a UCI `section server $name`: * `nginx-util add_ssl $name` will add to it: `option uci_manage_ssl 'self-signed'` `option ssl_certificate '/etc/nginx/conf.d/$name.crt'` `option ssl_certificate_key '/etc/nginx/conf.d/$name.key'` `option ssl_session_cache 'shared:SSL:32k'` `option ssl_session_timeout '64m'` If these options are already present, they will stay the same; just the first option `uci_manage_ssl` will always be changed to 'self-signed'. The command also changes all `listen` list items to use port 443 and ssl instead of port 80 (without ssl). If they stated another port than 80 before, they are kept the same. Furthermore, it creates a self-signed SSL certificate if necessary, i.e., if there is no *valid* certificate and key at the locations given by the options `ssl_certificate` and `ssl_certificate_key`. * `nginx-util del_ssl $name` checks if `uci_manage_ssl` is set 'self-signed' in the corresponding UCI section. Only then it removes all of the above options regardless of the value looking just at the key name. Then, it also changes all `listen` list items to use port 80 (without ssl) instead of port 443 with ssl. If stating another port than 443, they are kept the same. Furthermore, it removes the SSL certificate and key that were indicated by `ssl_certificate{,_key}`. * `nginx-util check_ssl` looks through all server sections of the UCI config for `uci_manage_ssl 'self-signed'`. On every hit it checks if the SSL certificate-key-pair indicated by the options `ssl_certificate{,_key}` is expired. Then it re-creates a self-signed certificate. If there exists at least one `section server` with `uci_manage_ssl 'self-signed'`, it will try to install itself as cron job. If there are no such sections, it removes that cron job if possible. ### Plan This change prepares Nginx for using UCI. So, the decisions here will influence Nginx's behavior. **Configuration:** I (still) think it is the best to give a standard configuration with a default server that uses a self-signed certificate (if SSL is enabled) <strike>and listens locally</strike> but listens on all IPs restricting the access locally. <strike>(This implies that other servers must also listen explicitly on local IPs to be reachable from LAN.)</strike> I do not see a possibility to achieve this without adding some configuration, which could interfere with existing custom configuration. To make it more smoothly, it would not use the new `_lan` default server from the `/etc/config/nginx` UCI configuration if the file `/etc/nginx/conf.d/_lan.conf` is still there (it will only be removed in a future change if it was not modified). This is done in the UCI configuration `/etc/config/nginx`. There are two versions of this file depending on whether Nginx is installed with or without SSL support, which could also be installed by the nginx package. Although, we could make the default server optional package(s), this would be different to all previous versions (there was always a default server, although there were differences if LuCI using Nginx was installed or not). Then other packages (e.g. `luci-nginx`, `luci-ssl-nginx`, `ariang` or `etesync-server`) could depend on the new package(s), and the default server is only installed then. IMHO we should *not* separate the default server in other package(s): This would only postpone problems of interference with previous configurations to the point when such a package is installed (and then it becomes more difficult to spot). And since this would be a bigger change, I would only do it if a maintainer of Nginx (@Ansuel and @heil) want it. **Main Functions:** The main purpose of this tool is to unify the workload of `/etc/init.d/nginx` with the functionality of `px5g` by the commands: * `init_lan` sets up the configuration for Nginx (faster than doing all in a shell script `/etc/init.d/nginx` that calls this function) * `add_ssl name' creates a self-signed certificates (like `px5g` but linked against `libopenssl`) setting up corresponding SSL directives in Nginx's config, too. * `del_ssl name` undoes that. Additionally there is a yearly cron job (if needed and cron is available) using the function: * `check_ssl` re-creates self-signed certificates if they would expire (in the next 13 months). This is how to interact with server $name: * delete it from config: `uci delete nginx.$name` * add self-signed SSL: `nginx-util add_ssl $name` * disable re-creation of self-signed certificate: `uci delete nginx.$name.uci_manage_ssl` or better: * remove self-signed SSL: `nginx-util del_ssl $name` * reload (all) config: `service nginx reload` **Proposed Timeline:** 1. Discuss these changes (until 11th of March draft PR) 2. Change and test these tools (until 22nd of March make PR) 3. Adopt the [wiki documentation](https://openwrt.org/docs/guide-user/services/webserver/nginx#configuration) (until end of March) 4. Change Nginx to setup the default server via UCI (using `/etc/nginx/uci.conf` if it is a symlink to `/var/lib/nginx/uci.conf` and removing `/etc/nginx/conf.d/_lan.conf` and `/etc/nginx/conf.d/_redirect2ssl.conf` for the SSL version until 1st of April make PR) Maybe, I will look into making some Nginx options available through LuCI afterwards. ### Questions There are some things, I am not sure how to do: * Should it use other directory/file names, e.g. `/var/etc/nginx/...` for dynamic configurations? * <strike>Should we install the UCI config with this package or with Nginx?</strike> (Here) <strike> Should we use `/etc/config/nginx-util` instead of `/etc/config/nginx` in the first case?</strike> (No) * <strike>How should we handle a `stream { … }` part in the Nginx configuration? Currently you have to edit the main `/etc/nginx/nginx.conf` file, which will not get updated if it was modified.</strike> (Setup manually.) ### To be changed (updated according to discussion) **Dynamically create the main configuration file and symlink `/etc/nginx/uci.conf` to it.** Prepared and edited above description: I changed it to include a `/etc/nginx/uci.conf.template` and to create `/var/lib/nginx/uci.conf` from it via `nginx-util init_lan` using servers of the UCI config in `/etc/config/nginx`. I would suggest to install the symlink by the Nginx package when adopting it to the new version of nginx-util. **In the testscripts use /bin/sh and shellcheck them.** Done. **Use allow/deny instead of listen locally** Done and edited the above description: there will be no `uci_listen_locally` …

github.com/openwrt/packages

nginx: use UCI config provided by nginx-util

openwrt:master ← peter-stadler:nginx

opened 09:44PM - 31 Mar 20 UTC

peter-stadler

+84 -413

Maintainer: @Ansuel and @heil Compile tested: MIPS 74K, Asus RT-N16, master sn…apshot Run tested: MIPS 74K, Asus RT-N16, master snapshot, run etesync-server with https Description: based on #11456 (details are there), the changes here are: * remove default configuration files and documentation as they are in the package `nginx-util`. * do not install a `/etc/nginx/nginx.conf` file. * create a symlink `/etc/nginx/uci.conf` -> `/var/lib/nginx/uci.conf`, where the `nginx-util init_lan` will create the actual configuration (from UCI settings and a template). * use the dynamic `uci.conf` if it is present (the symlink is not dead) after calling `nginx-util init_lan` (else `/etc/nginx/nginx.conf`) and check it by `nginx -t` when starting or reloading through `/etc/init.d/nginx`. * during boot wait for `interface.network.{lan,loopback}`: the reload is not triggered if the networks appear between `nginx-util init_lan` and procd starting the `nginx -c …` command ... **Edit:** Is there a better possibility? (Should the init_lan go into procd command?)

ricsvcr · June 1, 2020, 8:23pm

Hi Juppin, your comment put me back on the right track again. I installed nginx assuming it shared the same settings as uhttpd and that's what got me confused. I uninstalled nginx since I'm not really interested in using it at this time, and followed the steps in my second link (https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings) to verify and now I do see OpenWRT picking up the certificate. Then I used my self-signed certificates and after some tweaking I was able to generate a certificate that's compatible with modern browsers (includes SAN), validated by my own CA and that won't generate any errors in the browser.

Thanks your your help!

system · June 15, 2020, 9:45pm

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