Ultimate Chrome and Firefox browsers do not authenticate

jperezme

I have my captive portal configured to authenticate through https with self-signed certificate and the authentication page modified by me. Since some versions of chrome and firefox are not able to show add the exception to the certificate and therefore the portal can not redirect to the authentication page. However, edge and IE can. Anyone know how I can solve it?
Thanks.

Gertjan

Hi,

Hunt down some "@johnpoz " posts** where he explains step by step how to create a root ( "CAs" ) certificate, an intermediate certificate (also on the CAs page) and finally a certificate derived from them on the Certificate page.

Export de root and intermediate certificate.

Import the root and intermediate into the Firefox certificate store.

That should work - it did so up until now.

If not :
No more self signed certs for Firefox.
or
Use signed certs.

** he posted many posts about the subject.

free4

another possibility is to use a valid certificate for a subdomain that you own

using ACME (let's encrypt) plugin on pfsense, you could get valid certificates

jimp

Also watch out for OS-specific requirements. For example, recent versions of MacOS and IOS will not consider a new server certificate valid if it has a lifetime of greater than 825 days.

Gertjan

@jimp said in Ultimate Chrome and Firefox browsers do not authenticate:

greater than 825 days

Thank to ... you ! this is a not an issue since more then 2 years ^^

jimp

https://support.apple.com/en-us/HT210176

All TLS server certificates must comply with these new security requirements in iOS 13 and macOS 10.15:

TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.

TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.

TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

All things you should be doing anyhow, but the CA/Cert defaults in the GUI cover all of them except the new lifetime limit.

If you have certs made before July 1, 2019, then that lifetime limit doesn't apply (yet)

johnpoz

Are the devices that are going to use this captive portal under your control where they can bet set to trust your CA? If not this is good use of ACME certs..

Your own CA only makes sense when you control the devices that will be accessing the sites using certs signed by your CA.

And yeah the mentioned new 825 day limit can bite you if your certs are newer..