Messages

[-nokeys -nocerts]

Since I am only a beginner with the certificate-stuff it is not clear to me what I have to do with the -nokeys -cacerts-Option.

The -nokeys -nocerts parameters would create the PKCS#12 archive without the private key and server certificate. Only the CA certificate(s) would be included depending on whether you use -certfile cert.pem or -certfile cert2.pem (presuming your Intermediate CA cert was cert2.pem and not cert1.pem). You could then attempt to import them into the switch. This was to check if the switch accepts CA certificates without them being an extra certificate(s). We know it accepts server certificates, but what about CA certificates. I note this may not be a valid test anyway, depending on how Zyxel have chosen to process the bag. An alternative would be to export the Intermediate CA certificate in the GUI as a PKCS#12 archive and see if that can be imported. Does that make sense now?

But what is not clear to me is what is the benefit of generating the P12-File in the WebGui with including the certificate for the Intermediate-CA. Does any szenario has a benefit of the second certificate?

According to the relevant RFC, when setting up the HTTPS connection, a server (in this case your switch) is required to include all intermediate CA certificates in the certificate_list of the Server Certificate Message. The exception is the root CA certificate, which MAY be omitted from the chain specified in the certificate_list.

So essentially, the server is required to provide all the certificates in the chain except the root CA certificate, which should be in your certificate store if you trust it. That way, you only need the trust anchor, i.e. the root CA certificate, and the server will provide any other certificates in the chain.

It is noteworthy that normally, when including the extra CA certificates in a PKCS#12 export, the root CA would also be included, i.e. the whole chain would be in the bag. However, in the case of OPNsense only the issuer certificate is included. One reason could be convenience, as some certificate stores will hold multiple copies of the same certificate when it is imported. So if all certificates are imported, then this could result in multiple copies of the same root CA certificate (and issuing CA certificates) being present in the store, which can introduce additional management overhead. There are likely other compatibility or simplicity reasons for this, but I do note that it is possible this could change in the future and the root CA certificate could end up being included.

I only mention this in the event a vendor might wish to accommodate same, whether it be the presence of a root CA certificate in the PKCS#12 archive generally, or whether it be to check for duplicates before importing.

Is this for a web server on your LAN or another network segment routed from your LAN?
Are you serving your web server via an OPNsense reverse proxy, e.g. using NGINIX or HAProxy?
I would ask whether your OpenVPN clients are being pushed a gateway, but it appears they are...maybe...
It seems OpenVPN is working but you have an issue with clients connecting to the web server. Is that correct?

[-certfile filename]

I had a problem with importing a self-signed certificate...

And I have proofed, that the two certificates are different. The first one is the https-certificate and the second one is the certificate for the intermediate CA. The first one has 2136 chars whereas the second one has 2198 chars. The attributes shows that the issuer for the first certificate is my Intermediate CA and for the second one for the "root CA", so they are for sure different.

These two statements cannot be reconciled. By definition, a self-signed certificate has no chain of trust established by relevant intermediate (issuing) CA and root CA certificates; it is its own CA. What you likely have is a client certificate, and in this case I would hope it is a server certificate (it should be listed with "CA: No, Server: Yes" in the OPNsense GUI at System: Trust: Certificates).

If the above is true, it would appear the extra certificate is problematic for the switch. Looking at the User Manual I see no reason why the switch wouldn't accept the extra certificate, e.g. it doesn't specify that a self-signed certificate is required. That being said, the switch might not be capable of dealing with Intermediate CA certificates and may only give Issuer information.

More typically in IT device management - and despite best practice - the issuer of SSL certificates is a root CA rather than an Intermediate CA. The root CA certificate isn't usually included in the certificate_list of the Server Certificate Message, and so is usually not needed by the server (in this case your switch) when responding to clients. As such, your switch might not be expecting any extra certificates and therefore it might not have code to deal with an Intermediate CA certificate. An alternative possibility is that the switch is expecting the Root CA certificate to be present too, and when it cannot find it in the PKCS#12 archive it baulks...

You might want to try creating the PKCS#12 archive using the -certfile filename parameter (where filename is a file containing the CA certificates) to see if this also causes a failure. You might also try the -chain parameter instead, which will load all the relevant CA certificates from the local store, so perhaps this is more likely to work at the OPNsense terminal.

The extension of this is to specify the -nokeys -cacerts parameters to get a PKCS#12 archive with just the CA certificates to attempt to import.

There is some value in testing with the CA certificate file containing both CA certificates, but also with just the Intermediate CA certificate (-chain won't work for the latter, just specify an exported PEM copy instead using -certfile). Before importing, I would recommend checking the contents of each PKCS#12 archive you create using:

Code Select Expand

openssl pkcs12 -info -nodes -in certificate.p12

If the switch does successfully import a PKCS#12 archive with both extra certificates, then we could raise a bug report on OPNsense to include the root CA certificate too (it really should be imho). If instead, one of the PKCS#12 archives of just CA certificate(s) can be successfully imported, or the switch refuses to import any CA certificates, then I would suggest the issue needs to be raised with Zyxel. They should be able to advise what incompatibility might exist, whether it is a lack of capability in their implementation, or an aspect of your archive or even the certificate, etc.

[openssl_pkcs12_export()]

It is exactly as I said...

Right, thanks for confirming that.

Looking at the source for the PHP openssl_pkcs12_export() function, I see the OpenSSL PKCS12_create() function is ultimately what does the heavy lifting. The man page for this function states:

If a certificate contains an alias or keyid then this will be used for the corresponding friendlyName or localKeyID in the PKCS12 structure.

So in our case, when no friendly_name is specified, the PHP uses NULL and the OpenSSL function then uses the certificate alias for the friendlyName Bag attribute. Mystery solved..!

Any chance you could recreate the PKCS#12 archive with the following, and then see if it will import into your switch?

Code Select Expand

openssl pkcs12 -export -in certificate.crt -inkey certificate.key -name "friendlyName" -out certificate.p12
If it does successfully import, then we can eliminate the inclusion of the friendlyName Bag attribute as a cause.

The WebGui-generated File has the two different certificates...

Can you also please confirm the two certificates in the WebGUI-generated archive are indeed different? I expected them to be the same as it is self-signed. It could be argued that including a self-signed certificate as a CA certificate is a bug.

However, if they are not the same, then we would need to understand how they are related to one another in your particular environment, i.e. is one truly the issuer of the other, and if not why is the CA certificate being picked up...?! If there is proper cause for the inclusion of extra certificate(s), then the bug is likely with the switch (which could at least ignore the extra certificates).

Just to be sure, have you updated the switch firmware to the most recent version [4.80(ABMH.0)C0 dated April 27, 2023].

[openssl_pkcs12_export()]

...under the attribute "Bag Attributes" there is the attribute "friendlyName:" that is missing in the openssl-file.

Are you sure the friendlyName was missing in the manually generated file? I would expect it to be missing in the OPNsense generated file instead.

This is because the OPNsense code does not add a friendly_name key & value pair in the options parameter to the openssl_pkcs12_export() function (represented by the $args variable in OPNsense). Only the extracerts key is implemented, with the value being the first CA certificate found.

[--server]

Does your server set gateway options via --server or --server-bridge..? I would expect it does. Are you using --topology subnet too...? These usually PUSH a --route-gateway option.

If using --server-bridge (without arguments), there could be a problem with DHCP. If using --server-bridge nogw, the gateway will not be pushed at all.   

You could try a --route-gateway <gateway> with your client or push "route-gateway <gateway>" from your server, and see if that resolves your issue. If so, you could troubleshoot your server configuration to see if one of the issues above apply. It's possible that your server has been making use of a client bug, but without further troubleshooting it is not possible to determine where such a bug might be hiding...

Sorry, that happens sometimes. :)

Oh, the lulz... ;D

Problems like these...?

[openssl pkcs12 -info -nodes -in certificate.p12]

That is indeed interesting.

The two files differ in size. The p12-file that was downloaded directly in opnsense is ca. 20% bigger than the file that was generated with OpenSSL.

For the file you manually generated, and also for the file exported in OPNsense, what do the differences in output of the command openssl pkcs12 -info -nodes -in certificate.p12 reveal?

OPNsense makes use of the builtin PHP openssl_pkcs12_export() function, which includes the capacity to include a certificate chain. I suspect the PKCS#12 archive generated in OPNsense is including a CA certificate. Given that you are using a self-signed certificate, it is likely including itself as an extra. Maybe that is a problem for Zyxel kit. Maybe for others too.

Looking at the source, there doesn't appear to be any screening of self-signed certificates to prevent them from including extras.

I described some changes I observed in client behaviour here. Given @Sakata_T's contribution to that thread, I am minded to consider root causes not related to OpenVPN.

Although this noteworthy recent topic is perhaps unrelated, @Franco's contribution (beginning page 2) re troubleshooting might be beneficial to you.

That being said, if your server is not OPNsense too, perhaps it could be an incompatibility issue between your client and server now that OPNsense has moved to OpenVPN v2.6. What are you running on the server?

Just server instance. No clients

In that case, I am minded to consider root causes not related to OpenVPN.

Have you considered the discussion in this topic.

[--redirect-gateway def1]

I'm not seeing it on mine, but there have been reports of some gateway issues. OpenVPN gateway behaviour has changed, but if anything, it is arguable that it is now working as intended. I think the root cause is still perhaps somewhat ambiguous, and might not be caused by OpenVPN but by some other OPNsense component.

In your client configuration are you using --redirect-gateway def1 or similar?
Are you being PUSHed redirect-gateway def1 or similar by the server (check the log with client verbosity level set to 4+)?
Under Tunnel Settings, do you have the options Don't pull routes or Don't add/remove routes checked?

If you are being PUSHed redirect-gateway def1 or similar, you might want to check Don't add/remove routes and retest...

...the version that I've used is Win64OpenSSL-1_1_1t...

It is indeed the same version as presently used in OPNsense.

I'm curious what command you used - and whether the same command from an OPNsense shell would produce a working PKCS #12 archive too. Perhaps some additional parameters are required...

I'd say that could be due to differences in OpenSSL versions.

Was your Windows OpenSSL install v3+ by any chance?

[--cipher]

You may want to use both the --cipher and the --data-ciphers-fallback options. Depending on compatibility modes it should pick up one of them.

Ad and me suspected that this might work, but seems to be far from a desired outcome and likely prone to subtle issues depending on how it's being implemented now or in the future.

From OpenVPN v2.6.0, --cipher is always ignored in TLS mode and only used for PSK mode and when using --compat-mode version, neither of which are recommended. Clients connecting to remote legacy servers might still need it depending on the server version.

AFAICS even with 23.1.7 ciphers is still used in the server config - we removed that by using 'none' and using data-ciphers instead in the custom section, with a list of cyphers are clients need (and thus a road to upgrade ciphers) - this allows all our clients to connect and would be the proper fix for the variant introduced 21.1.3 (since as stated, ciphers itself is deprecated and will be removed with 2.7 AFAIR)

Presuming you're not doing so already, consider prefixing the --data-ciphers cipher-list with AES-256-GCM:AES-128-GCM:?CHACHA20-POLY1305:. That way as clients progress through your upgrade path they will also be able to make use of an AEAD cipher. Sacrifices of the list's constituent ciphers might be necessary to ensure it remains less than 128 characters in length...