No Luck Using a SSL Certificate with WebAdmin/User Portal

Hi,

Please use the shell to solve the problem.

Check the configuration in  /var/sec/chroot-httpd/etc/httpd.

In WEB-Interface you can see, that the UTM uses the right certificate. But in the config file you see the different! UTM uses an different certificate!

In case of using intermediate certificates you have to edit the configuration in  /var/sec/chroot-httpd/etc/httpd/vhost/httpd-portal.conf

SSLCertificateFile /etc/httpd/WebAdminCert.pem
SSLCertificateKeyFile /etc/httpd/WebAdminKey.pem
SSLCertificateChainFile /etc/httpd/intermediate1.pem
SSLCACertificateFile /etc/httpd/intermediate2.pem

MfG Stefan

Having the same issue here.  

This is what I used in OpenSSL.

openssl pkcs12 -export -out cert.pfx -inkey privatekey.key -in cert.crt -certfile intcacert.crt

I just don't believe the UTM is sending the intermediate CA.  I have a case open with support.  This issue has come numerous times.  In fact this thread goes back to Dec, 2013.  Something is wrong with the implementation in the UTM.

I'm not sure what you mean by "...I just don't believe the UTM is sending the intermediate CA."

• A router will never send an ICA or CA... those are used to authenticate the applicable certificates' validity that are negotiating the encryption of the encrypted traffic being sent and received.

The cert file needs to be a concatenated pem file as I've repeatedly stated throughout this thread, and I've also repeatedly addressed the above as well.  Please read back through my prior posts...

 A general FYI: Because I'm likely to respond with snark at this point, any other replies to this thread indicating a user did not read at least the last 10 posts, as well as other posts referenced, will not receive a reply and will be ignored.  I understand threads can span many pages, so asking one to briefly skim the last 10 posts, is not, I believe, asking too much.

See here, here, here, and here.

Perhaps if the whole thing was explained in one KB this would be easier to understand.  It's ridiculous to have to dig through a bunch of postings to figure this out.  The UTM should just handle the CSR generation and all the baggage that goes along with it to begin with.  Having to bring in a cert from Windows or OpenSSL shouldn't be necessary.

In your post here:

https://community.sophos.com/products/unified-threat-management/f/general-discussion/22147/no-luck-using-a-ssl-certificate-with-webadmin-user-portal/302338#302338

You state:

What I've assumed you've been trying to do is install a 3rd party signed WebAdmin cert into Sophos and have it so that you're not getting browser errors when navigating to the WebAdmin or User Profile pages.

Clients:

• [Windows]
  • Root CA will be imported into the Trusted Root Certification Authorites within Certificate Manager
• • ICA will be imported into the the Intermediate Certification Authorities within Certificate Manager

This is exactly what I am complaining about.  If the OS/Browser already trusts the CA why does it manually need to be installed in Windows?  That should only be necessary if you are using a self-signed cert.

What do you believe makes a browser trust a certificate, as it's not the browser...

Every OS comes pre-installed with root and intermediate CA certificates from the popular and trusted root and intermediate CAs (using self-signed CAs has nothing to do with it)... if an OS does not register a client/server cert as trusted, then one or two things are the cause of this (or both): either the root CA that signed the cert is not trusted in the certificate store [i.e. it hasn't been installed, or has been marked as not trusted], or the intermediate CA(s) is not in the certificate store.

• There can be multiple ICAs in a chain of trust, however the most I've seen commercially is two, with a chain of trust being: CA -> ICA1 -> ICA2 -> Client Certificate.
  • Client Certificate was signed by ICA2; ICA2 was signed by ICA1; ICA1 was signed by the root CA.
  • In this type of scenario, the root CA, ICA1, and ICA2 would need to be installed into the certificate store for chain of trust to be maintained.  The CA would go under root CAs, the two ICAs would go under the Intermediate CA category. The CA cert would likely be a concatenation of ICA2, ICA1, CA.

This is not an issue with Sophos, but a fundamental misunderstanding of certificate chain of trust.

"If the OS/Browser already trusts the CA why does it manually need to be installed in Windows"

Obviously the OS does not have a chain of trust for the certificate, else you wouldn't be having a chain of trust issue.  If you believe you do have a proper chain of trust, please do what I asked the other user to do here (bottom of post).

In Apache server and other HTTP servers, you can set the "CA Cert" OR you can concatenate the site cert with the hostname, the intermediate cert and signing CA. In the case of Comodo there are two intermediate certs: COMODO RSA Domain Validation and COMODO RSA Certification Authority. So you could concatenate the website hostname certificate, Comodo RSA Domain Validation and Comodo RSA CA into a single pem and set that in Apache as the "website certificate", then of course set the key file. What this causes Apache to do is that it provides the entire chained PEM file during the SSL handshakes, which provides the web client's browser the necessary intermediate certs to complete the chain of trust.

What appears to be wrong with the UTM is that even if the intermediates are all part of a single PEM, it is only sending the "site hostname" or "WebAdmin" cert, it's ignoring the intermediates entirely even if they are all concatenated. For example:

• cat sophos.domain.com.crt comodo-domain-validation.pem comodo-rsa-cert.pem >> sophos.domain.com-chain.pem
• openssl pkcs12 -export -out sophos.domain.com.net-chain.pfx -inkey sophos.domain.com.key -in sophos.domain.com-chain.pem -name "sophos.domain.com"

Uploaded the pfx file to the UTM and I set the WebAdmin to use that cert. Upon browsing to the WebAdmin, Chrome still shows a certificate CA validation error. Following the same procedure but uploading to an Apache server, everything works 100%. The issue does appear to be a problem with the UTM not sending all of the certs in the chain as part of the SSL handshake.

Perhaps I'm missing something, but where is the root CA in all of this?

• If ICA comodo-domain-validation.pem was signed by ICA comodo-rsa-cert.pem, where is the root CA that signed comodo-rsa-cert.pem?
  • This is the most likely cause of the error, as there's no chain of trust without the root CA that signed comodo-rsa-cert.pem

What does openssl say when you verify the moduluses of sophos.domain.com-chain.pem and sophos.domain.com.net-chain.pfx?

• openssl x509 -text -noout -in ./sophos.domain.com-chain.pem
• openssl pkcs12 -info -in ./sophos.domain.com.net-chain.pfx

 ...Following the same procedure but uploading to an Apache server, everything works 100%...

• I'm assuming this to mean you navigated to the Apache webserver's SSL webpage and there were no certificate errors in Chrome?
  • If this is the case, it's likely the system that web server is running on has the missing root CA installed as a part of it's CAcerts bundle

What is the exact error message Chrome is showing?  

• There is a known issue with Chrome and PolarSSL on Chrome v51+, however UTM uses OpenSSL
  • Chrome [v51+] requires AES-GCM and CAMELLIA-GCM ciphersuites to successfully handshake with a server using the ustream-polarssl backend.
    • If CONFIG_GCM is disabled, ssl_ciphersuite_from_id() will return NULL when cipher 0x9d is looked up ^{(TLS_RSA_WITH_AES_256_GCM_SHA384)}
    • This results with the call ssl_ciphersuite_match() to fail with POLARSSL_ERR_SSL_INTERNAL_ERROR ^{(RFC 5288)}

Does IE, FireFox, or any other browser throw an error (installed on same system as Chrome)?

• If they do, the problem is with the chain of trust and not browser related

What occurs in Apache if you specify the CA cert instead of concatenating it within the domain cert?

• What occurs if you create a p12 with the domain cert, domain key, and concatenated ICA-ICA-CA chain as the certfile?
  • If one is already utilizing a p12 for the web server, why not utilize the general form of providing chain of trust via the above bullet?
  • openssl pkcs12 -export -out ./sophos.domain.com.net-chain.p12 -inkey ./sophos.domain.com.key -in ./sophos.domain.com.crt -certfile ./ICA-ICA-CA_Chain.pem
    • Verify: openssl pkcs12 -info -in ./sophos.domain.com.net-chain.p12
    • Where ICA-ICA-CA_Chain.pem is:
      • cat ./comodo-domain-validation.pem ./comodo-rsa-cert.pem ./missing-root-CA.pem > ./ICA-ICA-CA_Chain.pem
        • Append [ >> ] shouldn't be used, as it allows for a mistake to be made (such as appending to an existing file)
        • Verify: openssl x509 -text -noout -in ./ICA-ICA-CA_Chain.pem

Also, does Sophos use Apache as it's webserver?  

• I can't check since my UTM is offlined at the moment due to issues within the last two updates resulting in the WAN uplink being wholly unreliable, plagued by repeated disconnects caused by something unknown within the last two updates.
  

The simple solution to all of this is installing the ICA and CA certs onto the client PCs; however, if one wishes to determine the cause, all the above will need to be sorted out.  The problem is most likely user error and not following the proper etiquette of providing certificate chain of trust, which would be the case since the root CA is nowhere to be found.

• While .pfx [Microsoft] can still be utilized, it's been depreciated for a while now, with .p12 [RSA Laboratories] superseding it

There's no reason to install the root and intermediate certs onto the clients.  If I go to that trouble I might as just use self-signed certs.  The root should already be on the client anyway.  And in reality the root shouldn't be necessary on the UTM either.

From RFC 5246 - certificate_list
This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

We also have an OpenVPN server running under Ubuntu.  I have had to replace the cert twice and have never had any trouble like this.  You are correct that pfx has been deprecated.  It's not correct, but the extensions are used somewhat interchangeably like saying SSL instead of TLS.  

I went ahead and spent $9 on a cheap cert tonight.  If I get a chance I'll try this all over again tomorrow on a different UTM.

Where do you believe root ca's are installed from?  The ether?  Perhaps they simply pop into existence in a puff of smoke on a PC?  From the information you've provided, your issue appears to be there's no certificate chain of trust back to the root CA that signed the 1st ICA.  What root CA signed that ICA?  Once you verify what CA it is, you'll then need to verify if that CA is installed on the client [under Trusted Root CAs] and Sophos [verification CA]... most likely, it's not (in the filesystem, it's saved as /var/chroot-httpd/etc/httpd/WebAdminCertCA.pem)

• I've been assuming you've read through the thread, as you should also have uploaded a complete chain PEM containing ICA2 -> ICA1 -> Root CA to the UTM as a verification CA

I'm well aware of the sequence of certs in a certificate chain... the chain would need to be configured in the way I listed.  I've spent hours writing and formatting posts on this thread, providing exactly how to do what one needs to do to maintain chian of trust; since I'm to the point of becoming snarky, best of luck to you.  

I encourage you to re-read what I wrote, specifically about verifying your certs, which you still haven't bothered to do.  Hopefully someone else takes pity, as I'll no longer reply to thread... the information you require has been given to you, it's your choice whether or not you're going to use it.  Cheers =]

 Oh and one other thing... the only difference between a commercial CA and a Self-Signed CA is the trust factor in the CRL.  When one purchases a certificate, one isn't paying for the certificate, one is paying for the management of the CRL and the layer of trust that results in.  Unless one has a website that will see random traffic (i.e. not the same pool of users), or processes financial information, there's nothing gained by going with a commercial CA.  In fact, more often than not, my Self-Signed CA & ICAs are more secure than many commercial CAs & ICAs... but again, what one is paying for is the CRL management.

Well I had a large posting with details but the forum filters decided it was spam.  So here's the short version.

After uploading the p12 bundle it looks like the files are stored here:

/var/sec/chroot-httpd/etc/httpd/WebAdminCert.pem
/var/sec/chroot-httpd/etc/httpd/WebAdminKey.pem
/var/sec/chroot-httpd/etc/httpd/WebAdminCertCA.pem

The top file only contains the site cert, no 3rd party CA info.  The file looks like output from this command:

openssl x509 -in certificate.crt -text -noout

The second one is the private key for the site cert.

The third file is a locally generated cert which contains info found in Management, System settings.

There's also a configuration file that references the files above.

SSLCertificateFile /etc/httpd/WebAdminCert.pem
SSLCertificateKeyFile /etc/httpd/WebAdminKey.pem

So if it's using WebAdminCert.pem it's never going to work because the 3rd party CA info is not in the file.

Pretty much what this post says:

https://community.sophos.com/products/unified-threat-management/f/general-discussion/22147/no-luck-using-a-ssl-certificate-with-webadmin-user-portal/59133#59133

I offer this as a solution.  Here's everything from the beginning.

Create CSR and private key in OpenSSL.

openssl req -out site.csr -new -newkey rsa:2048 -nodes -keyout private.key

Get your site certificate and CA certs from the CA.

Create PKCS12 in OpenSSL:

openssl pkcs12 -export -out site.p12 -inkey private.key -in sitecert.crt -certfile cachain.crt

sitecert.crt Your site certificate that came from the CA.

cachain.crt: I used the intermediate + root CA since the CA sent them together in a bundle. You may only need the intermediate CA but doesn't hurt to have both.  (Or more if needed)

UTM > Remote Access, Cert Mgmt

New Certificate

Give it a name, upload, PKCS#12, browse to file, provide password for file, save.

You should see your site cert in Certificates and the CA certs in the Certificate Authority tab.

Activate your new cert in Management, WebAdmin settings, HTTPs Certificate.

Test it: https://www.digicert.com/help/

The trust chain is most likely broken.

If so, combine the site cert, intermediate CA, and Root CA into a single file named WebAdminCert-fixed.pem.

-----BEGIN CERTIFICATE-----
<domain_name crt>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate CA crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA crt)
-----END CERTIFICATE-----

Turn on shell access in the UTM.

Upload the file to the UTM using WinSCP or another client.  I chose to upload it to /tmp.

Use putty or another client to SSH into the UTM as loginuser.

su root

cd /var/sec/chroot-httpd/etc/httpd

cp WebAdminCert.pem WebAdminCert.pem.bak

cp /tmp/WebAdminCert-fixed.pem WebAdminCert.pem

/etc/init.d/httpd restart

Test at: https://www.digicert.com/help/

Also make sure you can still login to the UTM Admin page before exiting the shell.

exit

exit

Turn off shell access.

Done!

I offer this as a solution.  Here's everything from the beginning.

Create CSR and private key in OpenSSL.

openssl req -out site.csr -new -newkey rsa:2048 -nodes -keyout private.key

Get your site certificate and CA certs from the CA.

Create PKCS12 in OpenSSL:

openssl pkcs12 -export -out site.p12 -inkey private.key -in sitecert.crt -certfile cachain.crt

sitecert.crt Your site certificate that came from the CA.

cachain.crt: I used the intermediate + root CA since the CA sent them together in a bundle. You may only need the intermediate CA but doesn't hurt to have both.  (Or more if needed)

UTM > Remote Access, Cert Mgmt

New Certificate

Give it a name, upload, PKCS#12, browse to file, provide password for file, save.

You should see your site cert in Certificates and the CA certs in the Certificate Authority tab.

Activate your new cert in Management, WebAdmin settings, HTTPs Certificate.

Test it: https://www.digicert.com/help/

The trust chain is most likely broken.

If so, combine the site cert, intermediate CA, and Root CA into a single file named WebAdminCert-fixed.pem.

-----BEGIN CERTIFICATE-----
<domain_name crt>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate CA crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA crt)
-----END CERTIFICATE-----

Turn on shell access in the UTM.

Upload the file to the UTM using WinSCP or another client.  I chose to upload it to /tmp.

Use putty or another client to SSH into the UTM as loginuser.

su root

cd /var/sec/chroot-httpd/etc/httpd

cp WebAdminCert.pem WebAdminCert.pem.bak

cp /tmp/WebAdminCert-fixed.pem WebAdminCert.pem

/etc/init.d/httpd restart

Test at: https://www.digicert.com/help/

Also make sure you can still login to the UTM Admin page before exiting the shell.

exit

exit

Turn off shell access.

Done!

This works great, however it seems that certificates are reset when the machine/VM is restarted. Might be a pain for those who restart occasionally.

Darn.  You are right.  I hadn't done a restart.  Must be getting copied back over from somewhere.

Robert

Robert Yount said:

Darn.  You are right.  I hadn't done a restart.  Must be getting copied back over from somewhere.

Robert

What is the resolution for this? Am running Sophos UTM 9.4.