Certificates Flagged as Invalid

Secure communication requires (a) talking to the right system, and (b) talking to it with encryption.   So the first step in a TLS session is confirming identity -- the browser verifies that the host identifier that you entered matches at least one of the host names returned in the server certificate.   It also does other verifications, include date range, certificate purpose, and signature chain leading back to a root certificate that was pre-installed on your client device.

Your error message says that the names do not match.   Certificate names are always fully qualified, so if you connect with an unqualified host name, you will see this error.   Similarly, if you connect using an IP address, you will see this error.   With a multiple-SAN certificate, UTM forces you to specify the name that it should offer when you configure the WAF site, so you must use the one FQDN that you configured into the UTM Virtual webserver.

You need to ensure that you have a name match for both client-to-WAF and WAF-to-Exchange connections.   You don't have to use the same FQDN for both connections, but it is harder to make a mistake if you keep them the same.  At minimum, the client and server side of each connection must use the same FQDN.

DouglasFoster said:

Secure communication requires (a) talking to the right system, and (b) talking to it with encryption.   So the first step in a TLS session is confirming identity -- the browser verifies that the host identifier that you entered matches at least one of the host names returned in the server certificate.   It also does other verifications, include date range, certificate purpose, and signature chain leading back to a root certificate that was pre-installed on your client device.

Your error message says that the names do not match.   Certificate names are always fully qualified, so if you connect with an unqualified host name, you will see this error.   Similarly, if you connect using an IP address, you will see this error.   With a multiple-SAN certificate, UTM forces you to specify the name that it should offer when you configure the WAF site, so you must use the one FQDN that you configured into the UTM Virtual webserver.

You need to ensure that you have a name match for both client-to-WAF and WAF-to-Exchange connections.   You don't have to use the same FQDN for both connections, but it is harder to make a mistake if you keep them the same.  At minimum, the client and server side of each connection must use the same FQDN.

 

Ok, so I access the Webadmin via IP address, so I should be seeing this is what you are saying.  Along with the error when a user tries to release or whitelist spam, as that uses the FQDN of the UTM.  So a solve for this would be to generate a request from the UTM to the CA for a certificate with at least the FQDN for the UTM so that internal users are not getting the message with the Release and Whitelist emails.

Equally, if the CA is correct for the Exchange certificate, how is the Invalid CA still an issues, as that is the only message that pops up when users try to access it via the internet?

Exchange Server Certificate

-------------------------------

It sounds like you have generated internal certificates rather than buying a commercial certificate.   For a server like Exchange, which needs to be accessed from the Internet, you need to spend the money to acquire a commercially-issued certificate.

I glossed over the certificate chain issue, but it is still related to proving identity.   You want to connect to mail.example.com.   Assume for a minute that bad guys used a tampered hosts file, a poisoned DNS server, or a NAT-translating device to redirect traffic from your intended server to a phony mail.example.com.    The bad guys send you a certificate that claims to be mail.example.com because they are going to some trouble to attack you.   How do you tell whether a certificate is trusted or not?   The answer is that you have to decide to trust certain entities to be Certificate Authorities  (CAs), which means that you trust them to only issue certificates for a name to the people who own that name.    You implement this trust by installing the CA's root certificate on your PC.

When a server sends a certificate that claims to be from "mail.example.com", it is typically signed by an intermediate certificate, and the intermediate certificate is signed by a root.   The intermediate certificate is supposed to be sent along with the identity certificate, but there are workarounds for servers that do not send it.   The root certificate has to be installed on the client PC in advance.   Some servers send it anyway, but this is also a configuration error because there is nothing gained and some trust lost by doing so.   The purpose of the root certificate is to prove that the other certificates were issued by somebody you trust and therefore the certificate can be trusted.

If you are using internally-generated certificates, the root certificate will have been deployed to your internal devices, but it will not have been distributed to your employee's home PCs, so your certificates will not be trusted.

If this has nothing to do with your situation, then you need to check whether you moved the certificate from Exchange to UTM correctly.  It needs to be exported with both the private key and the full certificate chain.    When you export the private key, you will always be asked for a password, and UTM will prompt for that password when the file is being imported.

Block / Warn messages about websites

When UTM blocks a web page, it has top mimic the remote webserver to reply with a block or warn page.   If the site is an HTTPS page, it has to convince the web browser that it is the remote site, so it generates a certificate from UTM's Web Proxy CA.   This root certificate has to be deployed to all of your devices for the block or warn page to display without certificate errors, for all the reasons explained above.

DouglasFoster said:

Exchange Server Certificate

-------------------------------

It sounds like you have generated internal certificates rather than buying a commercial certificate.   For a server like Exchange, which needs to be accessed from the Internet, you need to spend the money to acquire a commercially-issued certificate.

I glossed over the certificate chain issue, but it is still related to proving identity.   You want to connect to mail.example.com.   Assume for a minute that bad guys used a tampered hosts file, a poisoned DNS server, or a NAT-translating device to redirect traffic from your intended server to a phony mail.example.com.    The bad guys send you a certificate that claims to be mail.example.com because they are going to some trouble to attack you.   How do you tell whether a certificate is trusted or not?   The answer is that you have to decide to trust certain entities to be Certificate Authorities  (CAs), which means that you trust them to only issue certificates for a name to the people who own that name.    You implement this trust by installing the CA's root certificate on your PC.

When a server sends a certificate that claims to be from "mail.example.com", it is typically signed by an intermediate certificate, and the intermediate certificate is signed by a root.   The intermediate certificate is supposed to be sent along with the identity certificate, but there are workarounds for servers that do not send it.   The root certificate has to be installed on the client PC in advance.   Some servers send it anyway, but this is also a configuration error because there is nothing gained and some trust lost by doing so.   The purpose of the root certificate is to prove that the other certificates were issued by somebody you trust and therefore the certificate can be trusted.

If you are using internally-generated certificates, the root certificate will have been deployed to your internal devices, but it will not have been distributed to your employee's home PCs, so your certificates will not be trusted.

If this has nothing to do with your situation, then you need to check whether you moved the certificate from Exchange to UTM correctly.  It needs to be exported with both the private key and the full certificate chain.    When you export the private key, you will always be asked for a password, and UTM will prompt for that password when the file is being imported.

 

Block / Warn messages about websites

When UTM blocks a web page, it has top mimic the remote webserver to reply with a block or warn page.   If the site is an HTTPS page, it has to convince the web browser that it is the remote site, so it generates a certificate from UTM's Web Proxy CA.   This root certificate has to be deployed to all of your devices for the block or warn page to display without certificate errors, for all the reasons explained above.

 

Ok, so yes had to use a password for the Exchange certificate when exporting it from Exchange and importing it to Sophos.  So that should cover the Intermediate CA and the Root CA chain, if what I read is correct.  Internally all the computers have the Root CA and Intermediate CA's trusted through the domain.  There may be a few laptops that travelling users may not have installed the new certificate as of yet.  That can be fixed easily.  Yes an Internal CA is being used currently while funds are being appropriated for a commercial certificate.

The bigger issue is with the internal usage of Sophos for releasing or whitelisting emails.  When a user select the release or whitelist the address comes through as "https://UTM FQDN:port number/release.plc?proto=smtp,etc"  This is what is generating the Invalid CA and Sec_cert_CN_Invalid in Edge, and Firefox.  This is also where the mistake may have been made.  This is what I am more interested in fixing.  It seems the Web Proxy CA is not generating the correct certificate.  A new Web Proxy CA was generated, it has the current date.  It was downloaded with a password and distributed to the computers.  The issue still remains though with the Invalid CA and Sec_cert_CN flags.

DouglasFoster said:

Exchange Server Certificate

-------------------------------

It sounds like you have generated internal certificates rather than buying a commercial certificate.   For a server like Exchange, which needs to be accessed from the Internet, you need to spend the money to acquire a commercially-issued certificate.

I glossed over the certificate chain issue, but it is still related to proving identity.   You want to connect to mail.example.com.   Assume for a minute that bad guys used a tampered hosts file, a poisoned DNS server, or a NAT-translating device to redirect traffic from your intended server to a phony mail.example.com.    The bad guys send you a certificate that claims to be mail.example.com because they are going to some trouble to attack you.   How do you tell whether a certificate is trusted or not?   The answer is that you have to decide to trust certain entities to be Certificate Authorities  (CAs), which means that you trust them to only issue certificates for a name to the people who own that name.    You implement this trust by installing the CA's root certificate on your PC.

When a server sends a certificate that claims to be from "mail.example.com", it is typically signed by an intermediate certificate, and the intermediate certificate is signed by a root.   The intermediate certificate is supposed to be sent along with the identity certificate, but there are workarounds for servers that do not send it.   The root certificate has to be installed on the client PC in advance.   Some servers send it anyway, but this is also a configuration error because there is nothing gained and some trust lost by doing so.   The purpose of the root certificate is to prove that the other certificates were issued by somebody you trust and therefore the certificate can be trusted.

If you are using internally-generated certificates, the root certificate will have been deployed to your internal devices, but it will not have been distributed to your employee's home PCs, so your certificates will not be trusted.

If this has nothing to do with your situation, then you need to check whether you moved the certificate from Exchange to UTM correctly.  It needs to be exported with both the private key and the full certificate chain.    When you export the private key, you will always be asked for a password, and UTM will prompt for that password when the file is being imported.

 

Block / Warn messages about websites

When UTM blocks a web page, it has top mimic the remote webserver to reply with a block or warn page.   If the site is an HTTPS page, it has to convince the web browser that it is the remote site, so it generates a certificate from UTM's Web Proxy CA.   This root certificate has to be deployed to all of your devices for the block or warn page to display without certificate errors, for all the reasons explained above.

 

Ok, so yes had to use a password for the Exchange certificate when exporting it from Exchange and importing it to Sophos.  So that should cover the Intermediate CA and the Root CA chain, if what I read is correct.  Internally all the computers have the Root CA and Intermediate CA's trusted through the domain.  There may be a few laptops that travelling users may not have installed the new certificate as of yet.  That can be fixed easily.  Yes an Internal CA is being used currently while funds are being appropriated for a commercial certificate.

The bigger issue is with the internal usage of Sophos for releasing or whitelisting emails.  When a user select the release or whitelist the address comes through as "https://UTM FQDN:port number/release.plc?proto=smtp,etc"  This is what is generating the Invalid CA and Sec_cert_CN_Invalid in Edge, and Firefox.  This is also where the mistake may have been made.  This is what I am more interested in fixing.  It seems the Web Proxy CA is not generating the correct certificate.  A new Web Proxy CA was generated, it has the current date.  It was downloaded with a password and distributed to the computers.  The issue still remains though with the Invalid CA and Sec_cert_CN flags.

The quarantine release problem is a bug in the two most recent versions.   Hopefully, you will see a 9.511 release soon that has it corrected.