In my network OPNsense is handling the certs. I configured an automation to deploy the letsencrypt cert to nethserver. Looks like this in directory of root:
total 24
drwxr-xr-x 2 root root 72 Dec 31 13:15 .
dr-xr-x—. 24 root root 4096 Dec 31 13:14 …
-r–r----- 1 root root 3750 Nov 27 10:53 ca.pem
-r–r----- 1 root root 1541 Nov 27 10:53 cert.pem
-r–r----- 1 root root 5291 Nov 27 10:53 fullchain.pem
-r-------- 1 root root 288 Nov 27 10:53 key.pem
Right now nethserver is configured to use a self signed cert.
How can I use the certs from opnsense? No, I don’t want the acme challenge running on nethserver. I could not find any easy clearly pointed out how-to.
Easy. First, config setprop pki CrtFile /path/to/cert.pem, then config setprop pki ChainFile /path/to/ca.pem, then config setprop pki KeyFile /path/to/key.pem. And then, to set all the services appropriately, run signal-event certificate-update. You’ll need to re-run that every time you update the cert.
Clearly no update after signal-event certificate-update. Of course cockpit is not reachable.
Any ideas or suggestions? Did I overlook something?
EDIT:
From journalctl:
– Unit cockpit.service has begun starting up.
Jan 01 15:20:10 yy.xx.de remotectl[5266]: remotectl: /etc/cockpit/ws-certs.d/99-nethserver.cert: No PEM-encoded private key
How to update this one? This might be the reason for the error.
You told me “how”. With a standard letsencrypt cert deployed from an opnsense to neth7 it seems to be NOT easy. Meanwhile I read about the cockpit BUG with PEM encoded private keys. AFAIK, where possible one should use Elliptic Curve Cryptography encrypted certs. RSA is no longer suggested.
What Dan suggested does not work out of the box. Means a deployed standard letsencrypt cert from an acme challenge coming from an opnsense, gives the described error. If I understand correctly that’s why you opened the BUG in redhat bugzilla.
I think what you want to achieve is not really simple. If you want to use OPNsense to obtain the certificates it should also work as HTTP L7 proxy to internal servers, so they do not need to import and sync the certificates.
Right, it is not documented yet, however, since we just released a switch to ignore invalid TLS certificates I’d evaluate again NS8 (Traefik) as certificate handler. This is the issue reference:
OPNsense is fetching flawless all certs I have configured. HAProxy is configured and works correct, if I open port 80, 443 and 9090. BUT this server is not allowed to be reachable from the wan. Yes, I know, it’s more or less a cosmetical thing. I do trust my internal network.
Emails are handled on a separate dedicated email server. No problem to deploy from the OPNsense the letsencrypt cert for this server with an automation. Challenge type (for all certs) is http-01. Key lenght (for all certs) is ec-384.
Administration for all servers we run, is only allowed from the LAN or via VPN connection.
If it’s possible to import third party certs with the gui, it should be possible from the cli also. IMVHO it can’t be this difficult. Anyone who knows the commands?
I understand you are busy with NS8 - this question has no priority. Thank you anyway for taking time to look into.
I think is less messy have some automated check-and-pull procedure, rather than an automated push procedure.
(It’s only a cog position layout, not even a mechanism design)
Traefik should be instructed about:
what hostname should be considered interesting for the procedure
(with user/admin approval, list generated by the applications/containers/guest/how on earth should these things be called)
where the certificate can be retrieved
how can be retrieved
when the certificate match the pattern and is available, Traefik should compare to the one it’s using.
Certificate is the same? Check later™.
Certificate is newer? Pull it, store it, deploy to all the nodes, and declare when the nodes should use the updated one. Then schedule a prior certificate change for Traefik itself.