This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Web Protection With Subordinate CA

I was researching the idea of using a subordinate CA in Web Protection for HTTPS decryption and scanning.  The idea behind this is that, instead of trying to deploy/re-deploy a new certificate for this to function, that I would use a subordinate CA created using the root CA that is already trusted on my network.  See the following links for details regarding other web appliances:

https://www.websense.com/content/support/library/web/v76/wcg_help/ssl_sub_ca.aspx

Here is a link from Godaddy regarding just for informational purposes:

https://www.godaddy.com/help/what-is-an-intermediate-certificate-868

In any event, I attempted this with generically named cert, a wildcard cert, and a cert with the fqdn of my utm.  Unsuccessful.  I still get certificate errors when browsing secure websites with SSL decrypt and scan enabled.  Is the SSL decryption and scanning engine so fundamentally different in its implementation that this does not work or is that, actually, a bug?


It would be nice to get this working since it means not having to deploy/re-import another certificate through the network.



This thread was automatically locked due to age.
  • If I understand what you want, have you tried to upload the trusted root CA - on the 'HTTPS CAs' tab?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Yes, the trusted root CA is uploaded to the UTM.  One note, is that I have two, the old and the new one as I re-generated the trusted root certificate with a stronger signature.  I tried disabling the old one as a test but, same result.

  • So, I decided to follow up on this after some time and came across the following directly from Sophos:

    https://community.sophos.com/kb/en-US/115592

    Specifically, this:

    "If your organization already has an internally trusted certificate authority established and distributed, then using your own CA certificate will remove the need to distribute the public signing cert to your users."

    Now, in my above example, I had used a subordinate CA cert that was signed by my root CA but it "should" act in the same way, but doesn't.  The imported PFX file also was created with a PEM file that had the chain in it so the chain wasn't missing.  That brought me to this:

    http://ideas.sophos.com/forums/17359-utm-formerly-asg-feature-requests/suggestions/3044210-https-scanning-have-proxy-provide-certificate-cha

    The above seems to indicate that this is not possible, yet, contradicts what is provided in the Sophos KB.  Note that the more recent then the feature request mentioned above.

    Now, just as a test, I followed this article:

    https://social.technet.microsoft.com/Forums/office/en-US/41cf0b1c-a1b1-4d95-bddb-e677b69ed80c/exporting-private-keys?forum=winserversecurity

    It notes to export the root CA cert and key and import it into the security device.  I attempted that as a test since the root CA is trusted.  Again.  No dice.

    It would be nice if Sophos could clarify if this is/isn't possible and update their documentation appropriately.

  • You may need to concatenate the root CA certificate and the intermediate CA certificate together and then upload that.

  • I pem file I used to create the pfx I uploaded into the Sophos UTM contains both the subordinate CA and the root CA. 

    On a lark, I uploaded the certificate to the "Local verification CAs" as well, just for giggles.  No change. 

  • Ok.  I do remember that the cat order is important,as well as doing it in either linux natively or making sure you are not using windows mode rather than unix mode when doing it in Windows.  I assume you probably used linux, though.  Good luck with it.  I am out of ideas for now.

  • I did swap the CA and the subordinate cert order in the pem file to see if that would work but it did not.  I'm using Windows but I used OpenSSL for Windows to perform all the certificate work, save the actual signing which is done with a Windows CA.  Everything else from the pem, f12, pfx, keys, etc was done with OpenSSL.

    I honestly don't know what you mean by Windows Mode rather than Unix Mode.

    I'm curious if anyone has gotten this to work?  If anyone has a support contract, it would be nice to bring this to the attention of Sophos.  Other web appliances support this method so that you don't have to go around re-doubling your efforts to import ANOTHER certificate to computers and devices on your network.

  • It means if you just cat the files using notepad or something, linux will not like the file due to the crlf codes windows uses that linux does not.

    Copy the pem files (individually) to the UTM and then cat file.pem >> file2.pem and then use the resulting file2.pem as the certificate to load.

  • Hey, Euphrates.

    I had a similar setup running, and I used the very same document you pointed out to created a intermediate CA. I also had issues due to a misconception that my Windows clients would automatically trust any certificates issued by my Intermediate CA because they already trust Windows Root CA, but that's not the case. You will have to import the intermediate certificate issued to the UTM as a "Intermediate Certification Authorities" to every client for this to work. You can do this by using GPO:

    All in all, the only way to use HTTPS scan and avoid importing a new certificate to your clients is to export your Windows Root CA, import it into UTM and use it as a HTTPS CA. That is, assuming you are using an Enterprise CA and your clients are automatically receiving your Windows Root CA through AD. If you use a Standalone CA, you will also need to import your Root CA as a "Trusted Root Certification Authorities" in any of the cases.

    Regards - Giovani

  • Hello,

    i have seen this post

    , there its working like a charm and i don't understand why.

    Regards,

    Davide