Messages

I actually kind of like the idea of forcing any plugin/optional services to simply listen only on local interfaces, and having ingress handled by some kind of ingress proxy like nginx or haproxy or something.

It can simplify the network configuration of the local services by really eliminating the need for the services to do tls individually and rely on the configured ingress to do the work - also reduces the attack service to only soemthing explicitly configured for.

It is also a bit more of an advanced configuration though that could confuse those with less experience.

I think this will be my approach going forward :)

I did a little more digging to and the way the Acme plugin works is it specifically imports the cert into the opnsense trust store separately as CA and Cert.  See:
https://github.com/opnsense/plugins/blob/master/security/acme-client/src/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php#L112

for the ntopng plugin
https://github.com/opnsense/plugins/blob/master/net/ntopng/src/opnsense/scripts/OPNsense/Ntopng/generate_certs.php

It looks like (but i'm far from a php expert) that this is simply grabbing the cert and formatting it into the proper location and not acquiring the CA that's sepraately imported.

I actually ended up working around the problem similar to what you described with nginx. I just set up ha proxy configuration for it and the haproxy plugin properly pulls the cert and the intermediate CA

I was the OP :)  and yes my language use is not as pedantic as it can be because, well i'm just not that pedantic of a person :)

While technically you're right, it's not fullchain without theroot and you don't usually want to include the root, in every conversation i've had dealing with ssl/tls issues, the usage of full chain is usually implied to be cert + intermediates.

I Qualys finally fixed their cert tester, but many many years ago, it would actually issue a "Contains Anchor" warning if your server returned the root, but if it didn't it would issue a "Missing Anchor" warning.  So even that tool couldn't agree with itself which was appropriate :).  It took them a long time before they removed the "Missing Anchor" warning :)

Opened this issue
https://github.com/opnsense/plugins/issues/4707

Might be considered a feature request :)   We'll see.

the certificate is not expected to contain the chain

you're right, the cert doesn't contain the chain.  However, the mechanism that the server loads the cert CAN include a file that contains both.  Looking at:
https://www.ntop.org/ntopng/securing-ntopng-with-ssl-and-lets-encrypt/

Code Select Expand

root@myntopng:/home/deri/ntopng # cat /etc/letsencrypt/live/myntopng.ntop.org/privkey.pem /etc/letsencrypt/live/myntopng.ntop.org/fullchain.pem > ./httpdocs/ssl/ntopng-cert.pem
Note that they recommend using fullchain.pem

Code Select Expand

# grep CERTIFICATE--- /usr/local/share/ntopng/httpdocs/ssl/ntopng-cert.pem
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

The ntopng-cert.pem file that is created by opnsense only contains one cert.  It is missing the full chain which is necessary for ntopng to present a the cert fully.

It is supposed to work that way if you're dealing with intermediate certs.
Here's an example using https://letsencrypt.org/

Code Select Expand

$ openssl s_client -connect letsencrypt.org:443 --showcerts
Connecting to 2600:1f18:16e:df00::65
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E5
verify return:1
depth=0 CN=letsencrypt.org
verify return:1
---
Certificate chain
 0 s:CN=letsencrypt.org
   i:C=US, O=Let's Encrypt, CN=E5
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Apr  6 13:03:58 2025 GMT; NotAfter: Jul  5 13:03:57 2025 GMT
-----BEGIN CERTIFICATE-----
MIIEAzCCA4qgAwIBAgISBdBGoj4CNEX5P2CnVO1k1hlSMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
NTAeFw0yNTA0MDYxMzAzNThaFw0yNTA3MDUxMzAzNTdaMBoxGDAWBgNVBAMTD2xl
dHNlbmNyeXB0Lm9yZzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABLCiTBYLHyAh
0QyHvAzrlMYlVSYFuSwL4/E53SW95JorcZNJ3kIYm1q/EzA3aSL18cerF0Jv+Xcu
xCLTbQjKErejggKWMIICkjAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0lBBYwFAYIKwYB
BQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFJDLArKzImH/
YBJENl+2XXKkBda9MB8GA1UdIwQYMBaAFJ8rX888IU+dBLftKyzExnCL0tcNMFUG
CCsGAQUFBwEBBEkwRzAhBggrBgEFBQcwAYYVaHR0cDovL2U1Lm8ubGVuY3Iub3Jn
MCIGCCsGAQUFBzAChhZodHRwOi8vZTUuaS5sZW5jci5vcmcvMG8GA1UdEQRoMGaC
CWxlbmNyLm9yZ4IPbGV0c2VuY3J5cHQuY29tgg9sZXRzZW5jcnlwdC5vcmeCDXd3
dy5sZW5jci5vcmeCE3d3dy5sZXRzZW5jcnlwdC5jb22CE3d3dy5sZXRzZW5jcnlw
dC5vcmcwEwYDVR0gBAwwCjAIBgZngQwBAgEwLQYDVR0fBCYwJDAioCCgHoYcaHR0
cDovL2U1LmMubGVuY3Iub3JnLzgzLmNybDCCAQUGCisGAQQB1nkCBAIEgfYEgfMA
8QB3AKLjCuRF772tm3447Udnd1PXgluElNcrXhssxLlQpEfnAAABlgto8QYAAAQD
AEgwRgIhALQT7pCiTqcuSgDcKOuI+n6HV4SVY4rOHHmARRQMu7MZAiEAv1K9yHLo
elIsYuYHEooLs4WAi89C7O3aS/eHpO/Sdh8AdgB9WR4S4XgqexxhZ3xe/fjQh1wU
oE6VnrkDL9kOjC55uAAAAZYLaPKhAAAEAwBHMEUCIQDns62KoMl/obfhXOBpWoxM
qCLQ+TIA6FGyQqLIFj4uIwIgRrgu9lgI9iEoPU8AC39IPxoAWLppPUjNMT0TCppm
5v0wCgYIKoZIzj0EAwMDZwAwZAIwLgRga5fycj6i7WqdSAw9P15cUjc6aJS8g1yN
GikhWD5EfbjfyuSQiwI7pm8M9RZLAjAc84d37tx1tlMwvcQPlraksxz6u+7dEhQU
yMAibftFFh5FLnrSbal2vCGr5BlIzII=
-----END CERTIFICATE-----
 1 s:C=US, O=Let's Encrypt, CN=E5
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
-----BEGIN CERTIFICATE-----
MIIEVzCCAj+gAwIBAgIRAIOPbGPOsTmMYgZigxXJ/d4wDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjQwMzEzMDAwMDAw
WhcNMjcwMzEyMjM1OTU5WjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCRTUwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQNCzqK
a2GOtu/cX1jnxkJFVKtj9mZhSAouWXW0gQI3ULc/FnncmOyhKJdyIBwsz9V8UiBO
VHhbhBRrwJCuhezAUUE8Wod/Bk3U/mDR+mwt4X2VEIiiCFQPmRpM5uoKrNijgfgw
gfUwDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
ATASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBSfK1/PPCFPnQS37SssxMZw
i9LXDTAfBgNVHSMEGDAWgBR5tFnme7bl5AFzgAiIyBpY9umbbjAyBggrBgEFBQcB
AQQmMCQwIgYIKwYBBQUHMAKGFmh0dHA6Ly94MS5pLmxlbmNyLm9yZy8wEwYDVR0g
BAwwCjAIBgZngQwBAgEwJwYDVR0fBCAwHjAcoBqgGIYWaHR0cDovL3gxLmMubGVu
Y3Iub3JnLzANBgkqhkiG9w0BAQsFAAOCAgEAH3KdNEVCQdqk0LKyuNImTKdRJY1C
2uw2SJajuhqkyGPY8C+zzsufZ+mgnhnq1A2KVQOSykOEnUbx1cy637rBAihx97r+
bcwbZM6sTDIaEriR/PLk6LKs9Be0uoVxgOKDcpG9svD33J+G9Lcfv1K9luDmSTgG
6XNFIN5vfI5gs/lMPyojEMdIzK9blcl2/1vKxO8WGCcjvsQ1nJ/Pwt8LQZBfOFyV
XP8ubAp/au3dc4EKWG9MO5zcx1qT9+NXRGdVWxGvmBFRAajciMfXME1ZuGmk3/GO
koAM7ZkjZmleyokP1LGzmfJcUd9s7eeu1/9/eg5XlXd/55GtYjAM+C4DG5i7eaNq
cm2F+yxYIPt6cbbtYVNJCGfHWqHEQ4FYStUyFnv8sjyqU8ypgZaNJ9aVcWSICLOI
E1/Qv/7oKsnZCWJ926wU6RqG1OYPGOi1zuABhLw61cuPVDT28nQS/e6z95cJXq0e
K1BcaJ6fJZsmbjRgD5p3mvEf5vdQM7MCEvU0tHbsx2I5mHHJoABHb8KVBgWp/lcX
GWiWaeOyB7RP+OfDtvi2OsapxXiV7vNVs7fMlrRjY1joKaqmmycnBvAq14AEbtyL
sVfOS66B8apkeFX2NY4XPEYV4ZSCe8VHPrdrERk2wILG3T/EGmSIkCYVUMSnjmJd
VQD9F6Na/+zmXCc=
-----END CERTIFICATE-----

Note how their web site returns both the web server cert
 0 s:CN=letsencrypt.org
and the intermediate cert
 1 s:C=US, O=Let's Encrypt, CN=E5

This is what the ntopng port returns on my system

Code Select Expand

$ openssl s_client -connect <redacted>:3443 -showcerts
Connecting to <redacted>
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 CN=<redacted>
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN=<redacted>
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN=<redacted>
verify return:1
---
Certificate chain
 0 s:CN=<redacted>
   i:C=US, O=Let's Encrypt, CN=R11
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Apr  2 04:06:20 2025 GMT; NotAfter: Jul  1 04:06:19 2025 GMT

The intermediate chain is incomplete.

So not sure if I'm missing anything but I have a couple of lets encrypt certs managed by the acme plugin.  I have ntopng configured to use one of the certs and I just recently noticed (using curl) that the TLS cert chain is incomplete. The screenshot shows where I selected the acme generated cert (doctored it to show the web gui cert to not expose my internal info :))

The Let's Encrypt cert relies on an intermediate CA, and this configuration doesn't configure ntopng with the intermetdiate cert.  So tools that don't have lets encrypt's intermediate in their trust store fail to validate.  (easy to workaround, just add the intermediate cert to the trust store db of the client) but I'm wondering, am I missing something obvious?

Is there a way to configure the certificate to be full cert (including the cert chain) ?  I'm not seeing an option in the acme client to do this.

I use the exact same cert for the webgui ui (also lets encrypt generated).  This is set in System->Settings->Administration and that appears to be smart enough to know to pull the full cert chain.

So I'm a little confused what's going on with Kea.  There's a bunch of github issues and a couple of posts on here regarding whether or not Kea registers static and dynamic leases with unbound DNS.  There's one here https://github.com/opnsense/core/issues/7475 where it looks like it does not register dynamic leases with unbound.

But, just out of curiosity I gave Kea a try and it does seem to register dynamic leases except I've seen an interesting behavior on my setup.  I have 4 interfaces (3 of them are VLANs).  I only seem to get the non-VLAN (my primary LAN interface) entries registered with unbound.  All of the other interfaces do not have their dynamic lease hostnames registered with unbound.

I know I can workaround the problem with static leases and/or unbound DNS override entries, but given that one of the VLANs is my IOT vlan with lots of random devices, it's not a super scalable solution :)

Am I missing something here?

Thanks in advance for any thoughts.