Messages

166

General Discussion / Re: FreeRadius EAP Settings Root and Server Certificate

« on: November 03, 2021, 10:42:08 am »

My question is, if this is the correct way to have now 3 Certificates installed on the Client?

Yes, it would appear so, at least on a Mac. This is the full certificate chain. The leaf or server certificate is only trusted because the issuing or intermediate Certificate Authority is trusted. In turn the intermediate CA certificate is only trusted because the Root CA is trusted. The Root CA is the self-signed trust anchor.

Im also not sure yet, if under the EAP Settings Root CA the Intermediate CA or the Radius Root CA should be selected?

It is usually best practice to keep the Root CA offline and never use it to issue certificates except for an intermediate or issuing CA. As such, the intermediate CA should be selected here. If you look at the in-line help on the Services: FreeRADIUS: EAP page, you will notice it says:

Choose the Root CA [sic]. This CA will be trusted to issue client certificates for authentication. [Emphasis mine]

I can understand why it would be confusing, it clearly calls it a Root CA, but a Root CA should not be used to issue leaf certificates. It really should be changed to "Issuing CA".

What is the real benefit to have a intermediate CA in general?

The real benefit is that if the issuing or intermediate CA is compromised it's certificate can be revoked by the Root CA and a new intermediate CA established. Keeping the Root CA offline helps to mitigate this risk.

Having said that, I think OPNsense would need additional steps to preserve the Root CA offline. I'll raise that in the discussion being had here.

167

General Discussion / Re: Importing Intermediate (Issuing) CA Certificates

« on: November 03, 2021, 10:40:47 am »

Also...

How does one make the internal Root CA offline...?

Perhaps:

1. Export cert and private key to secure storage
2. Delete the CA
3. Import the cert but not the private key
4. Optionally, spin the Root CA up on alternate air-gap hardware

Will this impact certificates issued by an internal intermediate CA or the intermediate's operation?

Can CRLs for the internal Root CA still be published against the root CA certificate?

This topic for context.

168

General Discussion / Re: FreeRadius EAP Settings Root and Server Certificate

« on: November 02, 2021, 05:39:42 pm »

Awesome. 

...and everything is working now?

169

21.7 Legacy Series / Re: Remove Sensei swap

« on: November 02, 2021, 05:01:49 pm »

It might also be worthwhile dropping a post on the OPNsense Sensei Board to see if you get any takers...
Maybe just a link to this one...?

170

General Discussion / Re: Importing Intermediate (Issuing) CA Certificates

« on: November 02, 2021, 04:50:08 pm »

I think it was @fraenki ) And yes, yet another example of unpredictability: order matters.

It was Frank..! Franco just summed it up in one line. 
I think this particular "unpredictability" has probably graduated to a "known issue".
I'm a little surprised it hasn't been addressed upstream, but not really at the same time... 
I guess it comes down to maintenance of the store, whether that is by the upstream sources, by OPNsense devs or by the user.

I did like the idea of your blacklist - at least in principle. I should note that almost all competitor products have a CA certificate management capability. This could be accommodated in the existing view by adding a model populated by the upstream source(s). UI controls would probably best be dis/enable (or edit, but disable/enable would be better) and export but without delete. It would likely be helpful to display the fingerprint too (including for internal and imported certs). As for the controller, I am admittedly not at all familiar with what's specifically implemented, but it would require pointing to a new "edited" store, whether in config or mounting over the top of the upstream. Food for thought I guess.

could the version of curl used in OPNsense be compiled without that support? Would that solve this problem?

afaik latest versions of curl have an option to disable this flag. but this does not change the fact: applications can use intermediate certificates in the store differently

I should note I remain somewhat unconvinced that there is an inherent risk (due to unpredictability) with the importation of intermediate CA certificates. Rather, I think it is a matter of needing good store management and minimum standards for application selection (I'm thinking of curl and the partial_chain option).

Regarding building chains from config rather than the store (after supplying the leaf certificate):

technically yes. but it is very conveniently implemented in core and imho the devs will insist on forming chains in this way. the plugins mentioned do it in the manner indicated.

When doing config, would there be any value to selecting certs from the store in a drop down list, e.g. how it works now when setting the Web GUI SSL Certificate...? Just the same for issuing CA certs when needed. Or is that how it is already implemented..? 

Regarding the display of CAs in the Certificates store:

to quickly understand the purpose of the imported certificate? (an administrator might accidentally import a non-server or CA certificate)

It's certainly informative. 

I think this is potentially a significant problem. OPNsense should really be checking CRLs at the distribution points specified in each CA certificate.

as far as i could find in the code, this is only used in openvpn with internal CA. and certainly does not affect the behavior of client apps in any way

Firstly, I should say my comment quoted here is wrong:

As the certificate is imported in PEM format and not DER, doesn't that mean that CRL distribution points are not imported (or acted on).

The required extensions are still exported in PEM data: CDP (CRL Distribution Points) and AIA (Authority Information Access: used to publish issuing CA certs and OSCP Responders).
 
My concern was that OPNsense, when validating chains or behaving as a client (a relying party), might ignore CDP and AIA extensions (when present). Many clients aren't bothering anymore. Does OPNsense core or HAProxy or nginix even do CRL checking or OSCP verification or stapling? Are any of these verification techniques default behaviour for OpenSSL (presuming that this or LibreSSL are what all of core and the plugins rely on), or would such checks need to be invoked deliberately...?

I think this is more an issue for internal services, especially in enterprise use cases, where immediate revocation might be required. Many browser implementations don't even bother anymore. Yet, accessing my internal LDAP, ERP, CRM, SSH, email systems (whether webmail or fat-client) and intranet pages - well that could be a different issue...

It's noteworthy that AIA could potentially be used to prefill config fields for OPNsense core and plugins. For that matter it could supply clients with issuing CA certs too. I just don't think it's being used anymore...

171

21.7 Legacy Series / Re: Remove Sensei swap

« on: November 02, 2021, 04:22:05 pm »

A malloc device. Fun.

You will need to find the config file which contains the path "/usr/local/sensei/output/active/temp" to drop it (/dev/md43) methinks. Then just a reboot should do it...

You will need to alter the grep command. You might need to include all files instead of just "*.conf" files and search for an expression with the above path (or maybe use grep options "-Flr" and try the straight string), e.g.:

grep -Flr '/usr/local/sensei/output/active/temp' /

Better check my syntax. It could take a while too.

172

21.7 Legacy Series / Re: Remove Sensei swap

« on: November 02, 2021, 02:03:13 pm »

I've only got the rootfs device, but it's a bit meaningless to compare methinks. The others are just the floppy and the process filesystem.

Maybe try df -h to see what is mounted...

And grep -lr --include "*.conf" 'temp' /usr/local/sensei to get a list of conf files with the word "temp" in them.

You will likely need to change some of those options... 

173

21.7 Legacy Series / Re: Boot delay after "Invoking start script newwanip" (boot takes about 13 minutes)

« on: November 02, 2021, 01:30:06 pm »

So far it looks like more related to the OPNsense core than to the "VPN" topic.

Respectfully, IMHO, I disagree.

I'm having no problem with my boot times whatsoever while running multiple OpenVPN clients.

I think you are running clients too @karlson2k, yes...? @Maarten is running servers.

I think it worthwhile sharing your VPN logs, redacted if /as necessary so we can eliminate this as the cause.

No one else has offered any advice as to how to log boot with more verbosity. So this might be where we need to start. I know mine is working so I can compare time stamps, etc. to see what might be happening.

If there's nothing to be seen in the VPN logs, I might be prepared to spend a little time getting some logging runing for the 10-newwanip script and the configctl interface newip commands.
 

174

21.7 Legacy Series / Re: Boot delay after "Invoking start script newwanip" (boot takes about 13 minutes)

« on: November 02, 2021, 12:03:24 pm »

@Maarten: You may also want to post this question to the VPN Board.

Given it's been a long standing issue, it might be better suited to that board.

Methinks it more likely to be seen by a VPN gun there as well.

175

21.7 Legacy Series / Re: Migrating HAProxy configuration to new firewall hardware

« on: November 02, 2021, 11:24:23 am »

Kudos and credit be to Fright (if I'm not mistaken) for spotting the typo and for writing the patch.

In relation to migrations:

I would start on the same version. The most recent stable would be best because it will minimise differences and should help with support if you need it. I think you would be asking for problems migrating between different versions.

Unless someone else has a solution, a simple one, I think this is howto:
1. take backup on old installation
2. take a backup of new installation (same version as old installation I guess, or you will find more differences)
3. copy the old installation backup to a specific editable file
4. compare backup files so that one can change the interface names in the newly copied editable file
5. load the edited version on new installation

However I hope there is a better way to do this.

...and from the same topic...

I would also make sure any added plugins be installed on the new hardware that exist on the old hardware.
Also custom files need to be copied to the new hardware. And, of course, adjust the interfaces as needed...

So you have essentially done the same. I'm not sure if backup and restore also captures your HAProxy config; perhaps it does. If so, maybe it could be included in the technique above. If not, it possibly could be included through some plugin mechanism or coded into the backup. Whilst it is likely of some benefit, I believe writing some sort of diff wizard / editor for the restore process would not be a trivial piece of work.

As you still need to install OPNsense on a new system before restoring the old config on to it, using dissimilar hardware shouldn't be too much of an issue. Having said that, a thorough parsing and review of the backup file would be highly recommended.

176

21.7 Legacy Series / Re: Can't access web server (jNextcloud) due to HSTS error

« on: November 02, 2021, 10:46:12 am »

Are you running a web proxy on your network, OPNsense or other?

Maybe something running WPAD and / or a proxy auto-config script...?

Maybe also check your proxy settings in Firefox...

177

21.7 Legacy Series / Re: List 4G/5G LTE Adapters for OPNSense?

« on: November 02, 2021, 09:55:41 am »

I use a NETGEAR LB2120 and a "spare" ethernet port on the firewall.

You could setup your WAN with an additional tagged VLAN (perhaps labelled WAN-4G) and trunk the two into a perimeter switch and then break out the VLANs to bastion hosts and ISP routers as necessary.

It does have an in-built router but I use mine in bridge mode.

I like how it's all ethernet. It works well in a gateway group and OPNsense works well at directing traffic to particular gateways as needed.

It's showing it's age now though, I had to tape the last nano SIM into a micro cut-out. It might also have gigabit ports but it's maximum theoretical speed is 150Mbps.

NETGEAR have other options now too, such as the MR2100 with up to 2Gbps, but perhaps somewhat overkill with dual-band Wi-Fi and the works such as a colour touch screen, etc.

I'm sure there are a number of other players out there as well.

178

General Discussion / Re: Importing Intermediate (Issuing) CA Certificates

« on: November 02, 2021, 01:49:49 am »

in my understanding, this is not so much a curl bug as a flaw in the LE certs: curl uses the partial_chain openssl flag (it would be great if they documented it well, but who loves to mess around with the docs)). And imho if LE leaf (end-objects) certs contained all the fields in the authorityKeyIdentifier extension, then this would not happen, because openssl checks all extension fields to make sure the certificates match.

I mainly cited this as an example of possible unpredictability as a result of adding intermediate certificates to the store

I note your concerns re the LE certs. I think they are somewhat valid. I also note @franco's comments on GitHub around the ordering of certs in the store which I found interesting too.

Can anyone recall any other examples where importing intermediate CA certs has become an issue?

On curl's use of the partial_chain option with openssl verify, could the version of curl used in OPNsense be compiled without that support? Would that solve this problem? It might break something else I guess, but isn't use of this option providing an exploit vector?

afaik chains for services on OPNsense are based on config (not on trust storage)...

It would be good to get a definitive answer on this. I presume it would also be plugin specific too. This is what I meant when I asked if OPNsense was capable of such reverse proxy features, i.e. does OPNsense (whether core or plugin) build the chain based upon the specified server certificate, or does each feature require the chain to be configured? I presume each chain is verified by each server process upon startup, so perhaps it would be process specific...

I thought that this page only displays information from the cert itself (say "CA: No, Server: Yes")

Yes, but I wondered why, what is the benefit? And if a CA, why is it not in Authorities.

I note it appears that OPNsense does not download published CRLs for imported CAs but provides an import data field for X509 CRL data

I did not digg into this part, but I do not think that this is somehow used to change the normal operation of crl check, but is probably used to work internal services with internal CAs (for example, for the OpenVPN operations

I think this is potentially a significant problem. OPNsense should really be checking CRLs at the distribution points specified in each CA certificate. As they are imported CAs and not internal, the CRL distribution point is very likely to be external too. As the certificate is imported in PEM format and not DER, doesn't that mean that CRL distribution points are not imported (or acted on). Manually adding the CRL in x509 format to OPNsense means that a manual and non-authoritative CRL is used.

179

General Discussion / Re: Importing Intermediate (Issuing) CA Certificates

« on: November 02, 2021, 01:01:59 am »

There was a bug with PHP/LibreSSL caused by a bad update of PHP itself where CSR wasn't working, which is used internally for issuing a certificate/CA.

Not in this case... Fat thumbs maybe... 8^d

180

General Discussion / Re: FreeRadius EAP Settings Root and Server Certificate

« on: November 02, 2021, 12:50:16 am »

Both CA certificates should be imported into the client store to provide the full trust chain.

The server certificate usually doesn't need to be imported. I suspect that if you don't have the intermediate CA certificate (radius-intermediate-ca) imported it will offer both. With both CA certificates imported you should not be offered anything.

Try connecting without the server certificate (radius) imported to confirm this. IIRC, some RADIUS-backed EAP 802.1x implementations do require the server certificate to be installed, but it really shouldn't be necessary.