Make use of own letsencrypt cert deployed from opnsense

NethServer Version: 7.9.2009 up-to-date
Module: trust/certificates

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:

ls -la yy.xx.de/

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.

Thank’s for any help.

1 Like

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.

2 Likes

@danb35

Thank’s for hopping on.

Issuing the commands leads to:

systemctl status cockpit
● cockpit.service - Cockpit Web Service
Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor preset: disabled)
Drop-In: /etc/systemd/system/cockpit.service.d
└─nethserver.conf
Active: failed (Result: start-limit) since Mon 2024-01-01 15:07:33 CET; 1min 4s ago
Docs: man:cockpit-ws(8)
Process: 3101 ExecStartPre=/usr/sbin/remotectl certificate --ensure --user=root --group=cockpit-ws --selinux-type=etc_t (code=exited, status=1/FAILURE)

but:

systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/httpd.service.d
└─free_mutex.conf, quick_kill.conf
Active: active (running) since Mon 2024-01-01 15:07:20 CET; 1min 7s ago
Docs: man:httpd(8)
man:apachectl(8)
Process: 1393 ExecStartPre=/bin/bash -c ipcs -s | awk ‘$3==“apache” { print $2 }’ | xargs -r – ipcrm sem (code=exited, status=0/SUCCESS)
Main PID: 1416 (httpd)
Status: “Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec”

and in /etc/httpd/conf.d/virtualhosts.conf:

# 20forcessl_redirect enabled
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule (.*) https://%{SERVER_NAME}$1 [R,L]

#
#  20ssl_engine
#
SSLEngine on
SSLCertificateFile "/etc/pki/tls/certs/NSRV.crt"
SSLCertificateKeyFile "/etc/pki/tls/private/NSRV.key"

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.

Mhmm:

https://bugzilla.redhat.com/show_bug.cgi?id=1841070

Has this ever been backported/fixed?

1 Like

@danb35 and @davidep

Is there a way to use letsencrypt certs from opnsense? If so, how?

I already told you how. But it looks like Cockpit has a problem with ECC certificates, so you’ll need to get a RSA cert instead.

If I understand, you copied the certificate from another system.

The cockpit error message seems to say the cert is not encoded as it expects.

By memory, ecdsa bug was already fixed in 7.8.

So you have to inspect the cert content: what format is it?

Dan suggested to configure it with commands, but you could upload with the web UI too and get it validated.

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.

The server is up-to-date on NethServer 7.9.2009

rpm -q cockpit
cockpit-195.12-1.el7.centos.x86_64

rpm -q nethserver-cockpit
nethserver-cockpit-1.10.12-1.ns7.noarch

What do you mean? Is it fixed?

I saw this possibility in the web UI. These are the deployed certs from the opnsense. What exactly has to be linked to in the web UI?

Assuming this works, how/what are the steps to issue this from the command line? I’d like to automate this kind of tasks.

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.

It would also be interesting to learn how this problem could be solved with NS8.
Thank you.

The command to upload a certificate from ns8 root account is documented here: GitHub - NethServer/ns8-traefik: NS8 Traefik configuration

The API can be also invoked remotely with curl, after a cluster-admin token is obtained. The login process and the API protocol of api-server is described here: https://github.com/NethServer/ns8-core/blob/main/core/api-server/README.md

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.