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

The issue is occurring due to improper certificate etiquette... Whenever an Intermediate CA is involved, the Intermediate CA and CA must be concatenated into a single PEM in order to maintain hierarchy.

• cat "./IntermediateCA.crt.pem" "./CA.crt.pem" > "./Intermediate-CA-Chain.crt.pem"
  • The Intermediate CA is still used to sign the certs it issues; however, the CA - Intermediate CA chain cert must be exported with the client cert & key to maintain the certificate chain of trust of Certificate -> Intermediate CA -> CA. This allows for the certificate path of the client cert to show a hierarchy of CA -> Intermediate CA -> Client

Correct Layout

-----BEGIN CERTIFICATE-----

   ### Intermediate CA ###

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

              ### CA ###

-----END CERTIFICATE-----

 Once concatenated, the Intermediate-CA-Chain.crt.pem must be used in lieu of the signing certificate when creating the p12.

Windows will not be able to show both certificates in the PEM in gui form (it will only show the first listed, the Intermediate CA), however, if opened in a *nix OS, it will display both certs in gui form

Please note, Intermediate CAs and Certs cannot be utilized for Sophos VPNs due to the way in which Sophos authenticates the certificates.

Could someone please do an ELI5 version? I'm not really sure what to do here.

I have a GeoTrust RapidSSL installed and used by my web portal. However, I have some mobile client browsers (Android 4.2, I believe) that are showing the certificate as untrusted. Furthermore, when I test the cert using a tool like https://cryptoreport.rapidssl.com/checker/views/certCheck.jsp, it notifies me of a missing intermediate certificate.

I first tried uploading the intermediate cert as a PEM, to Certificate Authority. No change.

I then loaded the intermediate cert into a PEM file with my main cert, re-did the openSSL pks export, then re-installed that to my UTM. Both certs are listed (one under Certificates, the other under Certificate Authority). No joy. Test results are exactly as before.

If I SSH in, and look at WebAdminCertCA.pem, this is the original self-signed cert, not my freshly-uploaded intermediate cert.

Help me, Obi Wan...

It's generally best to read the last page/last 10 posts on a thread prior to posting.  Please see the last reply prior to your post 

JW0914 said:

It's generally best to read the last page/last 10 posts on a thread prior to posting.  Please see the last reply prior to your post 

You are assuming (incorrectly) that I have not. I have seen your post about the solution, but found it difficult to parse. Perhaps you could rephrase. Pretend I am 5.

Matthew said:

 

JW0914

It's generally best to read the last page/last 10 posts on a thread prior to posting.  Please see the last reply prior to your post  

 

You are assuming (incorrectly) that I have not. I have seen your post about the solution, but found it difficult to parse. Perhaps you could rephrase. Pretend I am 5.

 

The Intermediate CA and CA certificate must be concatenated into a single pem.  This is done easiest on a Linux/BSD distro, as both will display the two certificates in hierarchy when the concatenated pem is opened (utilize the cat command in my previous post to do so [concatenate]).

Windows [cmd, not ps, terminal]: type '.\ICA.crt.pem' '.\CA.crt.pem' > '.\ICA-CA-Chain.crt.pem'

While Windows won't display the concatenated cert correctly, you can still verify it with: openssl x509 -in ICA-CA-Chain.crt.pem -text -noout

*nix/BSD: cat './ICA.crt.pem' './CA.crt.pem' > './ICA-CA-Chain.crt.pem'

Once you've done the above, the concatenated CA needs to be uploaded to WebGUI, as well as installed on any devices accessing the WebGUI/User Portal.  If either the CA or the Intermediate CA is not signed by a central public CA, Android will throw a warning toast upon every boot.  This can be easily removed if the device is rooted, as the certificate needs to be moved from userland to system trusted (takes only ~3 min to accomplish).

Thank you for taking the time to repost! I believe I have followed your instructions, but am still unable to clear the intermediate certificate warnings.

To recount, my GeoTrust RapidSSL is installed on the UTM.

I obtained the recommended intermediate certificate bundle from https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO28836, which I understand is the required concatenation of intermediate CA and root CA. I saved this as a .pem file (I am on Windows), then uploaded it from the web GUI.

Retested at https://cryptoreport.rapidssl.com/checker/views/certCheck.jsp.

Still tells me the intermediate cert is missing. Could I have missed any steps?

Thanks, in advance.

Thank you for taking the time to repost! I believe I have followed your instructions, but am still unable to clear the intermediate certificate warnings.

To recount, my GeoTrust RapidSSL is installed on the UTM.

I obtained the recommended intermediate certificate bundle from https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO28836, which I understand is the required concatenation of intermediate CA and root CA. I saved this as a .pem file (I am on Windows), then uploaded it from the web GUI.

Retested at https://cryptoreport.rapidssl.com/checker/views/certCheck.jsp.

Still tells me the intermediate cert is missing. Could I have missed any steps?

Thanks, in advance.

I have the exact same symptom, and I have tried the suggested answer involving concatenating the two files into a single one.  I have tried re-generating the PKCS#12 file, I've tried uploading the concatenated CA (intermediate cert first) into the Certificate Authority tab, and just about every combo I can think of when generating the PKCS#12 file.  I can't get it to send the intermediate certificate out.

I'm currently using certs from StartSSL and I have this same symptom on two different UTMs with two different domains and certs.  Both are software UTMs but I don't think that plays a factor, does it?

What certificates are you including in the p12?  

• It should contain the following three files:  the concatenated ICA & CA [CA-Chain.crt.pem], the webadmin cert [webadmin.crt.pem], and the webadmin key [webadmin.key].

What do you mean by "...I have tried re-generating the PKCS#12 file, uploading the concatenated CA nto the Certificate Authority tab, and just about every combo I can think of when generating the PKCS#12 file. " &  "...I can't get it to send the intermediate certificate out."? 

• Sophos cannot utilize ICAs to issue certs.  I don't know why, however my guess is it has to do with security issues. 

• I believe an ICA signed WebAdmin cert can be utilized, but I'm not 100%.

Have you tried simply issuing the openssl command manually to create a p12?

• openssl pkcs12 -export -out '.\WebAdmin.p12' -inkey '.\WebAdmin.key.pem' -in '.\WebAdmin.crt.pem' -certfile '.\Sophos VPN CA Chain.crt.pem' 

• • The Intermediate CA is still used to sign the certs it issues, however, the CA - Intermediate CA chain cert must be exported with the client cert & key to maintain the certificate chain of trust of Certificate -> Intermediate CA -> CA.  This allows for the certificate path of the client cert to show a hierarchy of CA -> Intermediate CA -> Client 

• The OpenSSL utility can be downloaded for Windows or Linux/BSD.  If you need a preconfigured openssl.cnf, one can be found on my GitHub with all commands required at the bottom of the file, starting at line 546

Thanks for the reply.

Your suggested process to issue the pkcs12 is exactly what I have attempted in every way.  

• - The file listing you mention is exactly what I have used.  
• - The openssl command you listed is exactly what I have been using to create PKCS12 files.  
• - I have also attempted adding an additional -certfile command with each pem listed individually rather than in a concatenated file.  No change.  I've tried every combo I can think of with the same result in Firefox.
• - I've also tried downloading the CA and ICA files directly from Start SSL's site rather than using the bundled ones provided when the certs were issued to me.

At this stage, my belief is that the Sophos SG UTM does not send intermediate files to the client.  This is based on my results from multiple SSL test sites who state the intermediate or root certificate is not being sent with the response.

At this time, I do not know of an additional troubleshooting item I can attempt.

To clarify, please state exactly what you're trying to accomplish, because if it's the same as MatthewArciniega1, its user error.

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.

If this is the correct assumption:

1. Root CA and ICA need to be installed into each PC that will be accessing the WebAdmin and/or User Portals. 
   • [Sophos]
     • The Root CA and ICA will need to concatenated into a single pem and uploaded into Sophos via WebServer Protection -> Certificate Management -> Certificate Authority [Type: Verification CA].
   • 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
2. The Webadmin and User Portal cert are one and the same since they cover the domain name/public IP (if accessible from WAN) or host name/local IP (if LAN)
   • This cert (and it's key) does not get installed into any machine except the one running Sophos.  
   • [Sophos]
     • It should be uploaded into Sophos via WebAdmin, in the PKCS format, via WebServer Protection -> Certificate Management -> Certificates [New Certificate -> Method: Upload -> File Type: PKCS12]
       • The PKCS12 you generated with the WebAdmin cert, WebAdmin key, and concatenated ICA & CA pem as the signing authority
     • You will then need to set it as the WebAdmin cert via Management -> WebAdmin Settings -> HTTPS Certificate -> Choose WebAdmin/User Portal Certificate

I recommend verifying the PKCS12 and concatenated ICA & CA via openssl to ensure they have been correctly formatted, as if you're still receiving a chain of trust error, there's something wrong with how the concatenated PEM is formatted, or the proper CA(s) and ICA(s) have not been imported into the certificate store(s)

• Windows does not recognize a concatenated PEM as containing two certs and will only recognize the first cert listed in the text view of the cert.
  • In WIndows, the CA and ICA must be imported separately.  This may be the reason why you're having issues if the client machines are Windows, and if this is the case, simply importing the Root CA should solve this issue. 

I've attached a screenshot of what a concatenated ICA & CA should show for chain of trust (far left), and an accompanying client cert signed by the ICA (right).  

• If using Linux/BSD, the PEM will display two separate certificates when opened.
• If using Windows, you will need to import the Root CA first, prior to opening the ICA to view the cert.

If using Windows, you can have it recognize and display PEMs by saving the following to a .key file and importing into the registry (change registry version if yours isn't 5):

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.pem]
@="CERFile"
"Content Type"="application/x-x509-ca-cert"

Thank you for the very detailed response.  I'll try to be just as detailed in my reply.  I tried everything you showed and I'm no further ahead, I'm afraid.

Here is the exact command I am running to test and create my PKCS12 file:

openssl pkcs12 -export -out certificate.pfx -inkey private.key -in cert.crt -certfile chain.pem -chain

The chain.pem file is a concatenated file of the intermediate certificate and the root certificate, in that order.  This resulted in the following:

Error unable to get local issuer certificate getting chain.

When NOT using the -chain tag, the PKS file is created normally.  I upload that to the UTM into the >Webserver Protection > Certificate Management > Certificates

I have also uploaded the concatenated intermediate Class 1 certificate and the Root Certificate for StartSSL (from https://www.startssl.com/root ) to >Webserver Protection > Certificate Management > Certificate Authority as a "Verification CA".  Of particular interest, when I check where this is in use (using the {i} in the webadmin interface), it shows as in use by the certificate I uploaded in the previous paragraph.

I have tried creating the PKCS12 file with just the root, just the intermediate, the intermediate+root (concatenated), and root+intermediate (concatenated) with no luck.  Same chain error.

I still get firefox errors with no errors on Safari or Chrome.

What am I doing wrong?

Your PKCS12 command is incorrect and shouldn't contain the -chain flag in this situation.  I can't remember what situation it is required in, but it shouldn't be used when including a concatenated ICA-CA-chain.pem

What are the exact error(s) you're receiving in firefox?  Browsers will throw certificate errors for a variety of reasons, and if you're not getting errors with Chrome or Safari, then it's likely not a critical error; however, if you post the error message, I can do some research and get back to you.  My hunch is because it was issued from a signing authority still using the inadequate sha1 signing algorithm.

Just to verify, everything is working fine, with the exception of the firefox error?  I ask because I wasn't sure if the "...same chain error" was in reference to the FireFox issue or not.  If it's not, something is missing from the equation and you're going to need to use the OpenSSL verify commands to verify the modulus of each cert to it's issuing authority.  You're doing everything correctly, so I'm wondering if there isn't a second ICA involved that signed the ICA your cert is signed by.

Before squinting to compare moduluses, please list what the GUI chain of trust shows for the following certs [i.e. Certification Path in Windows]:

WebAdmin

ICA that signed WebAdmin

CA that signed ICA

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).