OPNsense Web Frontend shows correct certificate as "self signed"

[Zugschlus]

Hi,

I have an external CA (using EasyRSA on Linux). My OPNsense knows about that CA, it was imported via System => Trust => Authorities and is listed correctly in the CA list.

I then create a certificate signing request:

• System => Trust => Certificate and click on the Plus sign
• Select "Create a Certificate Signing Request"
  
• Enter Description
  
• Select parameters for Key Type, Digest, Lifetime
  
• Enter DN data
  
• Click "Save"
  
• Click on the Pencil at the just created Request
  
• Copy the Request from the data field
  
• Use my external CA to create the certificate as a server certificate
  
• Use openssl verify --CAfile ca.crt mycrt.crt, see it say "OK"
  
• Back in OPNsense, make sure that "Import certificate (signed by CA)" is selected
  
• Paste Certificate in field "Certificate data"
  
• Click "Save"
  

And then I notice that my certificate is listed as "self-signed" and that the Purpose says "id-kp-clientAuth".

When I copy the certificate from the OPNsense web interface again, I can use openssl verify and openssl x509 -text to verify that this is not a self-signed certificate and that it was made for a server.

I have OpnSENSE 25.1.10-amd64.

What is going wrong here?

Greetings, Marc Haber

[viragomann]

I had the same problem, when importing a certificate for an open CSR. I assume, this is a bug in OPNsense.

I got around this by saving private key from the CSR / certificate. Then I deleted the cert and reimported it with both values.
This procedure succeeded several times yet.

[Zugschlus]

I had the same problem, when importing a certificate for an open CSR. I assume, this is a bug in OPNsense.

I got around this by saving private key from the CSR / certificate. Then I deleted the cert and reimported it with both values.
This procedure succeeded several times yet.

Did you actually try to use the wrongly detected certificate? And if yes, did it work?

I don't think it makes much sense to generate a private key on the device and then to export it. That key is not supposed to ever leave the device.

Greetings
Marc

[viragomann]

I don't expect, that the private key works with a wrong certificate.
Strange idea.

[Patrick M. Hausen]

@Zugschlus please open an issue on github.

[Zugschlus]

I don't expect, that the private key works with a wrong certificate.
Strange idea.

Why do you think the certificate is wrong? I verified that the certificate is fine:

Code Select Expand

$ openssl verify -CAfile ca.crt test.crt
test.crt: OK

and both the private key and the certificate have the same modulus.

Greetings
Marc

[Zugschlus]

I had the same problem, when importing a certificate for an open CSR. I assume, this is a bug in OPNsense.

I got around this by saving private key from the CSR / certificate. Then I deleted the cert and reimported it with both values.
This procedure succeeded several times yet.

Did you actually try to use the wrongly detected certificate? And if yes, did it work?

I tried, it didn't work because OPNsense didn't let me select that certificate in the OpenVPN instance: "no CA found".

Greetings
Marc

[Zugschlus]

@Zugschlus please open an issue on github.

https://github.com/opnsense/core/issues/9357

[Zugschlus]

I had the same problem, when importing a certificate for an open CSR. I assume, this is a bug in OPNsense.

I got around this by saving private key from the CSR / certificate. Then I deleted the cert and reimported it with both values.
This procedure succeeded several times yet.

This seems to be a valid workaround. Hence, it breaks public key security as the private key will leave the OPNsense machine that way.

Greetings, Marc

[viragomann]

Hence, it breaks public key security as the private key will leave the OPNsense machine that way.

There is no need to keep the private key externally. Just delete it after importing.

[Patrick M. Hausen]

There is no need to keep the private key externally. Just delete it after importing.

If this is the private key of an OpenVPN client it should not be on OPNsense in the first place. It should never leave the system that uses it.

[Zugschlus]

There is no need to keep the private key externally. Just delete it after importing.

If this is the private key of an OpenVPN client it should not be on OPNsense in the first place. It should never leave the system that uses it.

It is the private key of the certificate used by OpenVPN instance on the OPNsense machine. I am pretty sure that this private key is needed on the OPNsense, hence it was created there and should never leave it.

Greetings
Marc

[Patrick M. Hausen]

It is the private key of the certificate used by OpenVPN instance on the OPNsense machine. I am pretty sure that this private key is needed on the OPNsense, hence it was created there and should never leave it.

But that works for me - just create a certificate and a key with the CA on OPNsense without going through the extra step of a CSR. Or did I read this all the wrong way round and your CA is not on OPNsense but somewhere else?

[Zugschlus]

It is the private key of the certificate used by OpenVPN instance on the OPNsense machine. I am pretty sure that this private key is needed on the OPNsense, hence it was created there and should never leave it.

But that works for me - just create a certificate and a key with the CA on OPNsense without going through the extra step of a CSR. Or did I read this all the wrong way round and your CA is not on OPNsense but somewhere else?

My CA is somewhere else.

I create a private key and a CSR on the OPNsense, paste the CSR to the external CA, paste the Certificate back to OPNsense and OPNsense sees it as self-signed.

The workaroound is to create a private key and a CSR on the OPNsense. Paste the CSR to the external CA. Then, copy the private key from the OPNsense to the clipboard, create a new Certificate record ("Import an existing certificate"), paste the privat Key there, then paste the Certificate. Then delete the certificate record that only has the key and the CSR.

Greetings
Marc

[Patrick M. Hausen]

Understood. So a bug, apparently.