Just for someone else with the same problem, I had a ticket with Sophos (for months just to get this answer...) because I didn't get this one working: https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Certificates/HowToArticles/CertificatesInstallSubordinateCAForHTTPSInspection/index.html#generate-a-certificate-signing-request-csr. Problem began for us in 18.5 but it is the same in 19.0 (don't know if this one worked ever...).
I was told that this is not possible. After I asked again that they want to tell me that the HowTo from themselves is wrong it was confirmed. So if someone want's to do this you have to do it another way against what the help will tell you...
To have some additional benefit from this topic: I can recommend the DigiCertutil for that purpose: https://www.digicert.com/support/tools/certificate-utility-for-windows
But as a last word here: for me it is ridiculous to wait for months for a useful answer and then the answer is simply "Yes, that's right it is not possible you can use the certificate used by CSR of Sophos Firewall for web services like UI access, WAF, etc...but not for proxy or email..etc." instead of: Yeah you are right, we are fixing it like described in the HowTo. At least it would be of sense to delete the wrong entry in the help asap...
Hello K-M,Thank you for reaching out to the community. Sophos do not provide a Private Key as it would breach on firewall security. You can import your own certificate with the private key + passphrase to use for Signing for Proxy and email signing. You can use the certificate used by CSR of XG for web services like UI access etc,
Thanks & Regards,_______________________________________________________________
Vivek Jagad | Technical Account Manager 3 | Cyber Security Evolved
Sophos Community | Product Documentation | Sophos Techvids | SMSIf a post solves your question please use the 'Verify Answer' button.
yep, somewhat clear but also wouldn't be necessary so technically this doesn't make sense as no one else but the firewall needs the private key for it... (I didn't want to have the private key just to make sure if this is clear).
CSR (and private key in background) is generated on Sophos XG, CSR is being signed in the external CA, public key is imported. Everything is still safe as no one needs the private key, it is already in the box and only needed there. It only has to match for it.
Seems, the Sophos-Artice is OK ...
Do you really do the part "Select Subordinate Certification Authority for your template" from "Open the CSR file you downloaded from Sophos Firewall, and copy the complete content without any extra lines. Select Subordinate Certification Authority for your template."Without the Sub-CA-template the resulting certificate could not be a Sub-CA ... which is necessary for HTTP/SSL-decryption.
And btw .... no public CA would sign your "Sub-CA".
Systema Gesellschaft für angewandte Datentechnik mbH // Sophos Platinum PartnerSophos Solution Partner since 2003 If a post solves your question, click the 'Verify Answer' link at this post.
Just do a test and try it... Without a test from your side it is not the answer and yes it is done like this.
And sure it is not a public CA (nobody suspected that here?). But how do you sign your SSL Decryption certificate? I hope from your own Root CA in your PKI.
Just to make clear: I can sign the CSR (with SubCA template!). But the public certificate generated out of this can't be imported into the firewall like described.
edit: and to strenghten my answer: Sophos itself says it is not working like you can read here in the thread...
This step is actually wrong:
You need to upload the signed CA to Sophos Firewall to use it for HTTPS scanning.
You need to add the CSR via Import. You did that? Or did you upload the Cert?
I did this a couple of years ago and it worked. Because this was part of the Architecture training, as far as i can remember.
So CSR import should work fine: docs.sophos.com/.../index.html
If I go to Import under the corresponding CSR there is only "certificate only" possible, everything else is greyed out.
CSR is already in the box, because it was generated there.
That is correct. The private key is already in the appliance. So you can upload the signed cer to the firewall.
as a "normal" certificate this is working like expected but you can't upload a (Sub-)CA certificate for signing this way...
That is correct. The CA and Root CA needs to be uploaded as PEM. I would not expect to upload it with private key.
hm? My Root CA is normally uploaded into the box (without the private key, for sure). But for HTTPS signing which is accepted from the clients there needs to be a SubCA (with private key) from that chain. And that one can't be uploaded if the CSR is generated from the XG (because private key is already and only in the box and the upload expects public/private keypair as it seems).
I just tried this and it worked fine. When I uploaded the completed certificate file after signing the CSR with AD CS, the other two options lit up and I could select "Certificate authority only" or "Certificate and certificate authority".
Are you 100% certain that you selected "Subordinate Certificate Authority" in step 4? The upload function does check to ensure that the certificate you are uploading has the necessary properties for a CA.
Funny, then you are the only person in this thread where this worked in detail/real life. Had a support ticket and nobody could solve it, even it is verified that Sophos will delete it from Documentation, see below. I would be interested in your exact steps how you did it. Maybe we could connect for a session, that you could show it to me how you do it.
Are you using a standalone CA for signing in a two tier pki? Then you also have to use the comand line on the offline CA? Or are you signing via GUI on the production/issuing CA?
Hi K-M - I made a quick video showing the steps I was taking. Perhaps you could have a look and see how it matches your experience. First, I just show that I already have the domain's root CA installed, then I go through the process of creating a CSR on the Firewall, signing it as a Certification Authority in AD then re-importing it to the Firewall.
Great, that is something we can work on. Don't know why the support was not able to add this useful information with OpenSSL as you are aware of it. Would have been easy to see that it can't be working without even trying to import it as my flag is FALSE!
BUT: it is only FALSE if the CSR comes from the Sophos itself. CSR generated externally are working just fine. Just did a parallel test with CSR from Sophos and from DigiCert utility. CSR from Sophos is FALSE, from DigiCert it is TRUE. So the template is right but there seems to be a problem in Windows CA while working with the Sophos CSR this way.
So we have the following differences:
- I am using a (offline) Standalone CA for issuing all SubCA certificates (two tier pki)
- In Windows Standalone CAs there are NO certificate templates in GUI available (there are no Templates configurable in MMC, too)
- SubCA Certificates CSRs are submitted like this: certreq -submit -attrib "CertificateTemplate:SubCA" "filename"
I send you a link to my test with screenshots. As there are internal information in it I can't link it here. There you can see in steps what I did.
OK, helped me searching the right way and I found it (that would have saved me hours with the support!). The problem is really the CSR from Sophos as it requests to be a single certificate for a device. Sorry, have only the german output from "certutil -dump csr".
Only the attributes are important, so I only will post this one here.
DigiCert csr (really short without any special):
Anforderungsattribute: 1 1 Attribute: Attribut: 1.2.840.113518.104.22.168 (Zertifikaterweiterungen) Wert , Länge = 23Zertifikaterweiterungen: 1 22.214.171.124: Kennzeichen = 0, Länge = 18 Alternativer Antragstellername DNS-Name=test-digi.test.localSignaturalgorithmus: Algorithmus Objekt-ID: 1.2.840.1135126.96.36.199 sha1RSA Algorithmusparameter: 05 00
Anforderungsattribute: 3 3 Attribute: Attribut: 1.2.840.1135188.8.131.52 (Kennwort in Frage stellen) Wert , Länge = 19 hHbLw2z9ENjdTdKbT9hRk5N Attribut: 1.2.840.1135184.108.40.206 (Unstrukturierter Name) Wert , Länge = 1a[...]
Attribut: 1.2.840.1135220.127.116.11 (Zertifikaterweiterungen) Wert , Länge = 36Zertifikaterweiterungen: 3 18.104.22.168: Kennzeichen = 0, Länge = 13 Alternativer Antragstellername DNS-Name=test.test.local 22.214.171.124: Kennzeichen = 0, Länge = 2 Basiseinschränkungen Typ des Antragstellers=Endeinheit Einschränkung der Pfadlänge=Keine 126.96.36.199: Kennzeichen = 0, Länge = 4 Schlüsselverwendung Digitale Signatur, Zugelassen, Schlüsselverschlüsselung (e0)Signaturalgorithmus: Algorithmus Objekt-ID: 1.2.840.1135188.8.131.52 sha256RSA Algorithmusparameter: 05 00
That has to be the same on your side. So it shouldn't be working at your side, too. BUT... now there is a Microsoft thing:
Important difference between Standalone and Enterprise CA is that if you use a Enterprise CA every attribute from the certificate template overwrites the attribute in the CSR, even if it is set. In a standalone CA the attribute will be kept if it is existing in the CSR despite what is beeing configured in the used template. So that is why it is working via the GUI on your Enterprise CA but not on my Standalone CA.
Additional Excurse: somewhere else stands that SubCA certificates should also be marked as critical (https://krestfield.github.io/docs/certdog/issuing-subca-from-microsoftca.html) and this is confirmed here (sorry german, https://www.gradenegger.eu/?p=1455) but that doesn't have an impact if it is already working. Maybe Sophos should take that in consideration if someone "fixes" the CSR generator and if you tick a button that this CSR is for SubCA it will be automatically requested as critical...
So if someone is looking into here please tell us if we have to open another case for it or if you discuss it internally on your own. Thanks in advance.
Thanks for sharing and providing the above information. I will go ahead and pass this on to our Documentation team.
That alone won't help in this situation. The generation of the CSR has to be changed, then the documentation can be adapted to the solution in my eyes. Maybe in the next version Microsoft handles it the same way in Enterprise CAs then it will not work at all...