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:
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
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
It shows the padlock with an exclamation mark and if you click on that it shows
showing that it is not secure due to having a security exception because the certificate is self signed.
