No intermediate certificate authority option

[Meg]

Hello. It is my first time trying to use OPNSense as a Certificate Authority, so I don't know if this is a change in this version or if it was changed some time ago. There does not seem to  be an option in the method dropdown to create an  intermediate certificate authority. Is this no longer required.

[Lilith]

Hi Meg - I'm also having this issue. The documentation here: (https://docs.opnsense.org/manual/how-tos/self-signed-chain.html) does not match the UI in 24.7. The only method options in Trust/Authorities is "Import," "Create Internal," and "OCSP."
There is a method option in Trust/Certificates called "Certificate Authority," but I wasn't actually able to use it to sign other certs.

I tried signing one CA with another CA to use as an Intermediate, but I receive an "UNKNOWN_ISSUER" error, even when the Root-CA is trusted on-browser. The chain of trust ends at the Intermediate CA -- it's the only BEGIN CERTIFICATE block on the cert.

[Meg]

Thanks for the reply Lilith.

[KritterFur]

Hi Meg - I'm also having this issue. The documentation here: (https://docs.opnsense.org/manual/how-tos/self-signed-chain.html) does not match the UI in 24.7. The only method options in Trust/Authorities is "Import," "Create Internal," and "OCSP."
There is a method option in Trust/Certificates called "Certificate Authority," but I wasn't actually able to use it to sign other certs.

I tried signing one CA with another CA to use as an Intermediate, but I receive an "UNKNOWN_ISSUER" error, even when the Root-CA is trusted on-browser. The chain of trust ends at the Intermediate CA -- it's the only BEGIN CERTIFICATE block on the cert.

Having the same issue. New user here. Any help would be appreciated.

[reunion974]

Same issue here. Any solution ?

[cookiemonster]

I've done this test:
In Authorities:
1. Created a new internal CA - to be the root.
Issuer: self signed
2. Created a second internal CA - to be the intermediate.
Issuer: the first CA
3. Created a CSR

In Certificates:
4. Sign the CSR created in step 3
The issuer from the drop down I selected as the second CA, so it acts as an intermediate.

When I look at the keyid of the  X509v3 Authority Key Identifier in the signed cert, I can see the ID of the "intermediate".
Can you check this works as it should?
I'm not stating this is how is meant to be used or that is right, but perhaps if you try, there is some hard data in this thread?

[Lilith]

Thanks so much for your reply cookiemonster. I followed your steps and can confirm that the Int-CA is readable from the server cert's chain when signing this way. However, I'm unable to export a private key for this cert and so can't test that it works against the root-CA installed in my browser. I'll keep working with it and try to shake out a usable test case

[Lilith]

Hi all - got a solution to my own situation which requires a bit of disco. Tested for Cockpit on Ubuntu 24.04
(Note: This is a workaround. There is still a discrepancy between OPNSense docs and this method, as I noted above.)

In OPNSense:
1. System > Trust > Authorities: Create an internal Domain Root-CA
2. ... > Certificates: Create a certificate with the following specs:
Method: Internal
Description: Domain Int-CA
Type: Certificate Authority
Issuer: Domain Root-CA
Save.
3. Edit this new Domain Int-CA certificate. Copy the Certificate Data and Private Key Data to your clipboard, or a text document
4. ... > Authorities: Create a certificate with Method: Import existing
5. Paste in the Certificate Data and Private Key Data. Save.
6. ... > Certificates: Create a server certificate issued by Domain Int-CA

Cockpit's documentation (https://cockpit-project.org/guide/latest/https) specifies that

The file should contain one or more OpenSSL style BEGIN CERTIFICATE blocks for the server certificate and the intermediate certificate authorities.

The private key must be contained in a separate file with the same name as the certificate, but with a .key suffix instead. The key must not be encrypted.

So I just did it by hand...

7. Download server's certificate.pem (I had to rename to server.crt for Cockpit) \
Download server's key.pem (I renamed to server.key) \
Download Domain Int-CA's certificate.pem (renamed to Domain-intCA.crt)
8. In terminal:

Code: [Select]

cat Domain-intCA.crt >> server.crt
## This adds the Internal Certificate's BEGIN CERTIFICATE block to the server.crt's chain, allowing it to be verified9. Transfer server.crt and server.key to the server and place in /etc/cockpit/ws-certs.d/ and then systemctl restart cockpit

I can now connect to server.domain with an SSL verified connection in Firefox after importing only my Domain Root-CA certificate.

Hope this helps someone!

[Lilith]

So... This long walk was educational, but unnecessary. After more testing, steps 1-5 can be more easily accomplished by just creating an Int-CA signed with a Root-CA in Authorities, as expected.

The underlying issue is that Intermediate CA certificates need to be installed server-side. Help guides suggest the installation method may differ depending on the host software, but both Nginx (https://nginx.org/en/docs/http/configuring_https_servers.html) and Apache (https://access.redhat.com/solutions/43575) documentation make chained certificates sound like the standard. OPNSense doesn't print these automatically from the download button - maybe functionality lost in the missing Authorities method? - so admins have to know to do it manually.

[cookiemonster]

I've been away. Glad is now sorted.
What you refer to is a situation that has existed since the beginning.
Some servers/applications/services utilise the "all in one" format. That is where the whole chain is in a single file.
Others require them in their distinctive blocks as separate files.
The user needs to know what theirs require and then split them or combine them if necessary from the source that produced them.
The .cert or .crt suffixes are also application dependent in a lot of cases.

[ssdanie]

Good evening,

After updating to version 27.7.6, I am no longer able to generate certificates with what I believe to be the correct Root CA and Intermediate CA chain.

The solution provided in post 5 doesn't work for me, or at least it doesn't behave as it used to.

When I generate a server certificate, to make it valid on my devices, I need to import both the Root CA and the Intermediate CA. However, shouldn't it be enough to just import the Root CA, or am I mistaken?

The issue doesn't occur with the WebGUI. If I use a certificate generated by my CA, importing just the Root CA is enough to establish a valid SSL connection, but this doesn't seem to be the case with other servers.

I suspect that the generated certificate lacks the Root CA data because, when I inspect the hierarchy from a browser, it stops at the Intermediate CA.

If I import the Intermediate CA as a root authority (in Windows’ trusted root certification authorities), it works. Otherwise, if I correctly import it among the intermediate certification authorities, I also need to import the Root CA. When both authorities are imported, the hierarchy appears correct in the browser, which I assume is more proper, as both authorities are installed on my PC.

Does this seem correct to you? Am I missing a step?

[Patrick M. Hausen]

When I generate a server certificate, to make it valid on my devices, I need to import both the Root CA and the Intermediate CA. However, shouldn't it be enough to just import the Root CA, or am I mistaken?

The client/browser needs only the root CA, but the server must be configured in a way to present both the server cert and the intermediate CA cert.

Like `SSLCertificateChainFile` in Apache httpd. Or in NginX place both the server cert and the intermediate CA cert into the same file.

[ssdanie]

The issue isn't with a private Apache or Nginx server, but with portals like HPE iLo, Synology web GUI, and even the Proxmox web GUI, which is easy for me to test. However, they don't present any problems if I use a Let's Encrypt certificate, for example.
In these portals, I don’t have much to configure:
i just upload the certificate and the key, and everything usually works, at least with other certificates.
I think I have an old OPNsense ISO and another Sense distro, and as soon as I have time to install them, I'll run some tests. However, it seems that the certificate generated by an intermediate CA set up this way doesn’t link the entire chain starting from the root CA.

[ssdanie]

"I just tested with OPNsense 23.7, and everything works perfectly:

1) I created my root CA,
2) created the intermediate CA signed by the root CA,
3) generated the server certificate signed by the intermediate CA,
4) imported my root CA into the Windows trusted root certificate store. The certificate is valid both in the Proxmox web GUI and in the HPE iLO web GUI. However, if I follow a similar process with OPNsense 24.7:

1) I create my root CA,
2) create a new certificate for an internal CA signed by my root CA,
3) import the intermediate CA via Authorities by pasting the certificate and key generated in step 2 (more complicated and long)
4) import my root CA into the Windows trusted root certificate store, the certificate is not valid because the entire certificate chain is not recognized."

[cookiemonster]

What you describe is a change in approach between versions to the way the downloaded certificate works. Before it included the chain, the new version doesn't and require the user to combine them.
There isn't a right or wrong. The two different approaches are valid and have been going for a long time. Just look at the two ways offered by commercial VPN services. It's the same. Some use combined, others not.
I suggest to create an issue in github to get the OPN devs to confirm.