Problems with https sites with SHA1 Certificate

Several issues are co-mingled here. 

1) The signature on a root certificate does not matter.   A root certificate is self-signed, so the signature is not used.  Since it is never checked, the method for checking does not matter.   The certificate is trusted because someone chose to install it on the client, not because it is signed.

2) The UTM CA for Web Proxy https inspection will issue SHA-2 certificates.   I don't remember which firmware update took care of this, but it was perhaps a year ago.  This is what matters. I don't have problems in my web browsers when I run with https inspection enabled.

3) UTM default settings for https inspection policy will be tightened with each release.  I know that has been blocking TLS1.0 sites by default for about a year, even though there are still some websites that cannot do TLS 1.2.   If you want to use these sites, a certificate-checking exception is needed.   I don't know if the version that you are running will block remote servers with SHA-1 certificates, but if it does, this is actually a good thing.   You can override it by configuring a certificate checking exception.

4) The UTM server identity certificate is used for WebAdmin, UserPortal, and possibly other functions.   It is an identity certificate, not a root certificate.  If you are using UserPortal for remote access, then it has to be internet-facing, so it needs to use a commercially issued server certificate, which will be SHA-2.   If you are using a self-signed certificate to save money, then the signature method is irrelevant.

4a) UTM has a problem in that when the server certificate is loaded, the intermediate certificate is discarded, so you don't have a valid certificate chain.   This doesn't really matter because all major browsers have the ability to fetch missing intermediate certificates using information from the server certificate revocation list parameters.  It may get dinged by a pentest vendor because it is suboptimal.   Sophos is aware of the issue and not moving fast enough to satisfy me, but it is not the end of the world.

5) A recent post in this forum announced that UTM does not do certificate revocation checking, and it has been handled as a defer-able feature request rather than a must-fix bug.   This bugs me a great deal, but is not a signature issue.

UTM has issues, but SHA-1 for web functions is simply not one of them.

UTM uses different CA roots for different purposes. 

• VPN has its own root certificate.  I don't know what the signature algorithm is for the user certificates generated by the VPN CA certificate.
• There may be one more CA root created, but I don't recall its function right now, as I am not using it and have not investigated.

Several issues are co-mingled here. 

1) The signature on a root certificate does not matter.   A root certificate is self-signed, so the signature is not used.  Since it is never checked, the method for checking does not matter.   The certificate is trusted because someone chose to install it on the client, not because it is signed.

2) The UTM CA for Web Proxy https inspection will issue SHA-2 certificates.   I don't remember which firmware update took care of this, but it was perhaps a year ago.  This is what matters. I don't have problems in my web browsers when I run with https inspection enabled.

3) UTM default settings for https inspection policy will be tightened with each release.  I know that has been blocking TLS1.0 sites by default for about a year, even though there are still some websites that cannot do TLS 1.2.   If you want to use these sites, a certificate-checking exception is needed.   I don't know if the version that you are running will block remote servers with SHA-1 certificates, but if it does, this is actually a good thing.   You can override it by configuring a certificate checking exception.

4) The UTM server identity certificate is used for WebAdmin, UserPortal, and possibly other functions.   It is an identity certificate, not a root certificate.  If you are using UserPortal for remote access, then it has to be internet-facing, so it needs to use a commercially issued server certificate, which will be SHA-2.   If you are using a self-signed certificate to save money, then the signature method is irrelevant.

4a) UTM has a problem in that when the server certificate is loaded, the intermediate certificate is discarded, so you don't have a valid certificate chain.   This doesn't really matter because all major browsers have the ability to fetch missing intermediate certificates using information from the server certificate revocation list parameters.  It may get dinged by a pentest vendor because it is suboptimal.   Sophos is aware of the issue and not moving fast enough to satisfy me, but it is not the end of the world.

5) A recent post in this forum announced that UTM does not do certificate revocation checking, and it has been handled as a defer-able feature request rather than a must-fix bug.   This bugs me a great deal, but is not a signature issue.

UTM has issues, but SHA-1 for web functions is simply not one of them.

UTM uses different CA roots for different purposes. 

• VPN has its own root certificate.  I don't know what the signature algorithm is for the user certificates generated by the VPN CA certificate.
• There may be one more CA root created, but I don't recall its function right now, as I am not using it and have not investigated.