Sophos XG - SSL certificate warning when accessing login for web interface

Hi Markus,

Go to Certificate > Certificate authorities > Download the "Default" certificate, this will be used to sign the request while access the UI on port 4444.

Thanks

Hi Sachin,

I already tried to download the certificate from the firewall (Protection > Web Server Protection > Certificate Authority => SecurityAppliance_SSL_CA) and

install it under Chrome - Settings - HTTPS/SSL - Manage Certificates... - Trusted Root Certificate Authorities,

but the message did still show up :-/

Any idea?

Cheers,

Markus

Edited

Nope,

I do get the same problem with the Internet Explorer, too.

This happens whenever I try to log in the firewall web interface: https://firewall-ip-address:4444

Wish there was a solution to this :-/

You aren't alone I spent some time trying to figure this out before giving up.

Hi charlesbruch,

thank you for cheering me up :-p

I think there has to be a solution to this!

Maybe Sophos has to add an option to replace the certificate with your own that meets the requirements :-D

Hey Sachin, please tell us there is a solution to this :-)

Hi..

The above process is required but you omitted the last step which is to change the inspecting authority to default instead of appliance certificate:

Hi Darren,

thanks for trying to help, but your hint is relevant regarding normal internet traffic.

We were talking about reaching the web admin of the firewall and all the browsers telling that the cert of the firewall is not safe.

Have a good day and cheers,

Markus

Hi Markus,

That is correct, because it is a self signed certificate from an untrusted CA (your firewall). 

If you have a trusted certificate already, you can import the CA in XG and generate CSR, sign it with your CA server and upload it on the firewall, from there onwards, the cert will be trusted.

Regards,

HI All, 

The certificate error you have received is due to Appliance certificate and would get the certificate error. This certificate won't make a difference even if its installed on the client machine. The Certificate issue can be resolved if you import your own certificate and use that certificate in Appliance Access also should be accessed via DNS instead of Host address. 

Excuse my lack of familiarity here but could I simply import one of the Microsoft Root Certificates in the picture?

If not, is there a private certificate to be easily used on a standard Windows 10 installation?

Thanks

 This thread is confusing the Certificate Authority - which is typically used for HTTPS man-in-the-middle decryption of proxied, with the appliance's own Certificate.

From what I understand, the poster is asking about the certificate that is used when you access WebAdmin at :4444.

First, go to Web \ Protection and make sure the HTTPS Scanning Certificate Authority is SecurityAppliance_SSL_CA.  This is the out-of-the-box value and if you changed it, put it back.

Now go to Certificate, Certificate Authorities.

The "SecurityApplicance_SSL_CA" is the Certificate Authority which will sign all the HTTPS traffic that the Web Proxy does.  Download and Install it all all end user clients that will proxying through the SFOS to far websites.

The "Default" is the Certificate Authority that will sign the HTTPS port :4444 on the appliance itself.  Download and Install it on any client that will access WebAdmin.

Note: If you uploaded or regenerated any CA, please do this extra step.  Under Certificates \ Certificates, there should be ApplicanceCertificate.  If you click the gear you can regenerate the certificate using the current default CA.

Now when you access WebAdmin, it will be using a certificate generated from the CA that you have installed.

However - and this is a known issue, the certificate will still not be valid.  This is not because of Certificate Authority, but because certificate that the SFOS generates will not have CN (common name) that matches the hostname.  This is in part because hostname is something that was added as recently a v16 (strange, I don't understand how Cyberroam UTM and the early SFOS could not have a hostname).

For FF, when they warn you about the invalid certificate, in the pop-up you are given the option to permanantly store this exception.
For IE, go into Options, Security tab and add the site to Trusted sites.
For Chrome, it uses the IE setting.  The navigation though settings is more complicated, just do it in IE.

That all being said -- you can just skip the CA stuff and add the exception/trust and I think that will work.

 This thread is confusing the Certificate Authority - which is typically used for HTTPS man-in-the-middle decryption of proxied, with the appliance's own Certificate.

From what I understand, the poster is asking about the certificate that is used when you access WebAdmin at :4444.

First, go to Web \ Protection and make sure the HTTPS Scanning Certificate Authority is SecurityAppliance_SSL_CA.  This is the out-of-the-box value and if you changed it, put it back.

Now go to Certificate, Certificate Authorities.

The "SecurityApplicance_SSL_CA" is the Certificate Authority which will sign all the HTTPS traffic that the Web Proxy does.  Download and Install it all all end user clients that will proxying through the SFOS to far websites.

The "Default" is the Certificate Authority that will sign the HTTPS port :4444 on the appliance itself.  Download and Install it on any client that will access WebAdmin.

Note: If you uploaded or regenerated any CA, please do this extra step.  Under Certificates \ Certificates, there should be ApplicanceCertificate.  If you click the gear you can regenerate the certificate using the current default CA.

Now when you access WebAdmin, it will be using a certificate generated from the CA that you have installed.

However - and this is a known issue, the certificate will still not be valid.  This is not because of Certificate Authority, but because certificate that the SFOS generates will not have CN (common name) that matches the hostname.  This is in part because hostname is something that was added as recently a v16 (strange, I don't understand how Cyberroam UTM and the early SFOS could not have a hostname).

For FF, when they warn you about the invalid certificate, in the pop-up you are given the option to permanantly store this exception.
For IE, go into Options, Security tab and add the site to Trusted sites.
For Chrome, it uses the IE setting.  The navigation though settings is more complicated, just do it in IE.

That all being said -- you can just skip the CA stuff and add the exception/trust and I think that will work.