@swami_ you can setup haproxy to use your wan or you lan interface. Comes down to where the traffic is going to hit.

Even if you ha proxy listens on you wan IP, unless you open a firewall rule on the wan that would not be available to internet IPs. But your wan IP is still going to be able to be hit via your lan devices.

Comes down to where you want to point the fqdn you want to use to point to - if all your going to want it for is lan, then just use your lan IP and point all your fqdn you want to use to your pfsense lan IP.

@coyotekg The client certs use the CA as the issuer just like the server certs do so yes, you would need to change them.

Still following the thread I mentioned above, I saw that the eval previously was right before RESULT=.
I have tried to comment the if statement block and move eval, so this way

# eval serial="\$tls_serial_${check_depth}" # if [ -n "$serial" ]; then eval serial="\$tls_serial_${check_depth}" RESULT=$(/usr/local/bin/php-cgi -q /etc/inc/openvpn.tls-verify.php "servercn=$2&depth=$3&certdepth=$4&certsubject=$5&serial=$serial&co nfig=$config") if [ "${RESULT}" = "FAILED" ]; then exit 1 fi # fi

and I don't get anymore the error on the certificate!
I don't know if I need to open an issue about this.

However, now I get the error about the user authentication

SENT CONTROL [spike]: 'AUTH_FAILED' (status=1)

like I was getting when I set "Certificate Depth = Do Not Check".
I looks like I'm not the only one having this issue.

@Bekoj said in TLS Error : something wrong with Certificates ?:

installed pfsense brand new in 2.4.5 version

installed pfsense brand new in 2.4.5 version

hmmm, next time I'll ask first...😉

@Gertjan "Oooohhhh. And you're telling that now ?"
Yes, we went around a bit, the point is, it's okay

@rafamello

Como pensávamos, o problema é com *.GOV + cert.

OK, I see the logic. Thanks.

@viktor_g I will update it as soon as possible.

After playing around for a little while I made an interesting discovery that I have not been able to find an explanation to...

FreeRadius EAP Settings has a check box "Check Client Certificate CN" ("When enabled, the Common Name of the client certificate must match the username set in 'FreeRADIUS > Users'").

When using a certificate to authenticate, it seems to me that the certificate CN would NOT be checked against the Users database. Regardless of the users I have added, I always get error messages like below when I have that check box checked:

Nov 30 17:33:15 radiusd 1388 tls: Certificate CN (K14) does not match specified value (host/K14)! Nov 30 17:33:15 radiusd 1388 tls: TLS_accept: Error in error Nov 30 17:33:15 radiusd 1388 (4) Login incorrect (Failed retrieving values required to evaluate condition): [host/K14/<via Auth-Type = eap>] (from client SW21 port 2 cli xx-xx-xx-xx-xx-xx) host/K14 -

So far I have not been able to figure how to effectively enable the client cert. CN check.

I wonder if this is also some stupid beginner's mistake, or is this something else?

And where does this "host/" prefix come from? At least it seems to be independent of the 802.1X authentication mode in the client (User vs. computer authentication)...

When the check box is not checked, authentication with the certificate succeeds without any problems.

FWIW, Radius debug log reveals:

(2) files: users: Matched entry host/K14 at line 2 (2) [files] = ok

...so it seems that it indeed performs the check against user database where I have an entry "host/K14".

Do it even easier:

Run acme package on FW1 (I assume it's a CARP cluster with syncing?) and let it create a certificate for both names (fw1.xxx AND fw2.xxx). When it's done, select the cert for the webui. Then login to FW2 and select it, too, as certificates get synchronized automatically (if selected) to the secondary. There choose the same certificate as WebUI cert and be done :)

Just check that you configure the acme service on fw1 to restart its own webserver after renewal AND via remote the service on fw2 (see the help for this)!

Greets

@jmurr
Человек явно написал свою специфику работы: чтобы браузер не ругался...

I want to setup multiple OpenVPN servers using a common CA, with the ability to revoke users from a central location.

It is likely that your VPN interface isn't enabled in pfSense. Open Interfaces and select the VPN interface that you added to System > Routing > Gateways and click the Enable box. Click Save.

Navigate to Status > OpenVPN and restart the service. It should show a green check mark and show local, virtual, and remote host addresses.

Would anyone have an idea as to what is going on? I'm kind of stumped at this point.

You would have to edit php file used when creating cert..

https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/system_certmanager.php

if ($act == "new") { $pconfig['method'] = $_POST['method']; $pconfig['keylen'] = "2048"; $pconfig['digest_alg'] = "sha256"; $pconfig['csr_keylen'] = "2048"; $pconfig['csr_digest_alg'] = "sha256"; $pconfig['csrsign_digest_alg'] = "sha256"; $pconfig['type'] = "user"; $pconfig['lifetime'] = "3650"; }

Keep in mind that would be reverted every time you updated pfsense and that file gets redone, etc.

Where are you getting your cert from? Your going to have to give us more details if you want anyone to be able to figure out what your doing wrong.

For what possible reason would you want to use a wildcard cert for the webgui? How many possible fqdn/IPs could you point to the web gui?

The web gui should be accessed by limited number of users. Create as cert with your own ca, have the users that will access it trust your ca. Put in whatever SANs you want to access it by. Done - set the cert to be good for 10 years. Never have to deal with this issue again.