IPFire certificate is insecure - NET::ERR_CERT_COMMON_NAME_INVALID

I also noticed that the IPFire certificate was displayed as insecure (NET::ERR_CERT_COMMON_NAME_INVALID) in Windows even when putting it in the Trusted Root Certification Authorities Certificate Store. After I recreated the certificate according to this tutorial wiki.ipfire.org - Generate an SSL-Certificate manually it’s working now:

Before:

After:

It seems IPFire creates a legacy SSL certificate during the setup without x509v3_config. Is the code in the setup too old to support the Subject Alternative Name?

It would be nice if this could be added in the next stable release. I don’t know if Linux users also get the certificate warning in the browser but it is really annoying.

If you forget to add the IPFire certificate to your own certificate store you will get: NET::ERR_CERT_AUTHORITY_INVALID

1 Like

That is correct.

At the beginning of this year a forum user updated that wiki page to follow the x509v3 approach but the same changes were not submitted as a patch into IPFire so nothing was modified.

I will pick this up and evaluate the changes made to the wiki and look at making the modifications to the code.

That won’t happen as Core Update 177 is already in Testing and will shortly be released.

Core Update 178 is close to being released for Testing.

Any patch update might make it into CU178 or it might have to be CU179.

I have Firefox running on an Arch Linux system and after making an exception for the certificate I get the following
Screenshot_2023-08-02_22-43-44
It shows the padlock with an exclamation mark and if you click on that it shows
Screenshot_2023-08-02_22-45-44
showing that it is not secure due to having a security exception because the certificate is self signed.

4 Likes

@bonnietwin That’s great news. :+1:

If you’re getting NET::ERR_CERT_COMMON_NAME_INVALID with IPFire on Windows, it’s likely because the default certificate lacks a Subject Alternative Name (SAN). Even if added to the Trusted Root store, browsers will still flag it. To fix this, manually recreate the certificate using IPFire’s guide: Generate an SSL Certificate. The new cert with SAN will resolve the browser warning. It would be great if future IPFire versions included SAN by default in the setup process.

I hope it helps!

That is my plan and it is on the list of things to do but the list is large and the team is relatively small.

So as always, anyone else is welcome to pick it up and submit a patch to the dev mailing list as per the documentation.

https://www.ipfire.org/docs/devel/submit-patches

Another alternative is to donate to the project.
Donations help to ensure the longevity and long-term success of the project. They help to fund developers and pay for our hosting.

The above takes money and every single donation counts and for IPFire to thrive we need everyones support.

The best way for anyone to do this is by setting up a regular donation to the project.

Thanks in advance for everyones support.

1 Like