Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 41 subscribers
  • Views 490 views
  • Users 1 member is here
Options
Suggested

Sophos Home v21 GA - Unable to upload internal CA

Herman Baum

I am trying to upload/update a custom CA for SSL decryption (signing and validation), but it fails with the following message:
"Hochladen der Zertifizierungsstelle ist fehlgeschlagen. Ungültiger privater Schlüssel oder ungültiges Kennwort"
I know the passphrase for the key is correct, because it works if I upload it on the certificates page, just not on the ca page.

If I try to upload the certificate without the key the error is:
"Die Zertifizierungsstellen-Datei ist möglicherweise beschädigt"

I have compared the old and new crt file using this command on a linux workstation in my homelab:
diff -u <(openssl x509 -noout -text -in /tmp/old.pem) <(openssl x509 -noout -text -in /tmp/new.pem)

The only differences are the expected date, serial number and public key.

The article used: docs.sophos.com/.../index.html

Details to the certificate:
- Sub-CA of internal root CA

        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)

        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: critical
                OCSP Signing
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0

    Signature Algorithm: sha256WithRSAEncryption

Details of the private key:
- 4096 Bit
-RSA

What are the requirements for a ca certificate? Unfortunately the article is very thin here.



Added private key details.
[edited by: Herman Baum at 5:34 PM (GMT -8) on 7 Jan 2025]
Parents
  • 0

    Translating the german, I wonder if the format of the file is not what it expects.


    Does your PEM file look like

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


    Have you tried the cut&paste method rather than file upload?


  • 0 in reply to Michael Dunn

    Also just in case there is a super edge case, can you try switching to English in the login screen.  I have only seen it one case of it, in a different part of the UI, but there was a string compare that failed if the language was not English.

  • 0 in reply to Michael Dunn

    Hello Michael,

    thanks for the suggestions.

    I have tried copy and paste. Same result unfortunately. Also my file looks exactly as you suggested.
    Inspecting the certificate and private key file on the advanced console using the openssl binary on the appliance is also working fine.
    In addition both files are correctly recognized on my linux workstation as well.

    Do you happen to know what that correct format / the format it expects might be? I could't find any documentation on that detail apart from being a PEM encoded file.

    To my surprise the upload is working fine when I try to upload it under "Zertifikate" -> "Zertifikate" instead of "Zertifikate" -> "Zertifizierungsstelle (CA)"
    I recognizes the certificate and the private key with its passphrase correctly.

    But I cannot select it for decrytption from there. It seems it must be uploaded under "Zertifizierungsstelle (CA)".
    I probably should also mention that I have tried updating/replacing my current sub CA with a new certificate and new key as well as adding it completely new. Thats how I got the error for about the certificate format being wrong, while at least to me, it looks completly fine.

    I have also tried it while switched to English but it resulted in the same behaviour.

  • 0 in reply to Herman Baum

    I think the issue may be due to the Extended Key Usage options that are included in the certificate file.

    The signing CA certs that I create for firewalls typically show the following:

    X509v3 Extended Key Usage:
             TLS Web Client Authentication, TLS Web Server Authentication

    Whereas yours just shows 'OCSP Signing'.

    I tried creating a certificate like yours, from what you show - RSA4096 key, but with only 'OCSP Signing' in 'Extended Key Usage'. When I attempted to upload this certificate I get the same error (in english: 'Certificate authority file may be corrupt').

    I then recreated the cert to include TLS Web Client Authentication and TLS Web Server Authentication, and it uploaded fine as a CA.

    X509v3 Extended Key Usage:
             OCSP Signing, TLS Web Client Authentication, TLS Web Server Authentication

    Finally, I created another cert without the Client Auth flag, and it was also accepted.

    X509v3 Extended Key Usage:
             OCSP Signing, TLS Web Server Authentication

    So I think that the CA validation on upload requires that the Extended Key Usage section of the certificate includes 'TLS Web Client Authentication'.

    How to add this flag will depend on how you created and signed the certificate. I was using openssl and so I had to edit the configuration block in the CA's config file for signing sub-CAs. In Windows CA, you would need to edit the certificate profile used to sign/issue the certificate.

    Update: I also tried creating a certificate with no Extended Key Usage constraints section (similar to the built-in CA file in every device). This uploaded fine as well. So the validation rule is: if there is an Extended Key Usage section, it must contain the Server Authentication flag.

Reply
  • 0 in reply to Herman Baum

    I think the issue may be due to the Extended Key Usage options that are included in the certificate file.

    The signing CA certs that I create for firewalls typically show the following:

    X509v3 Extended Key Usage:
             TLS Web Client Authentication, TLS Web Server Authentication

    Whereas yours just shows 'OCSP Signing'.

    I tried creating a certificate like yours, from what you show - RSA4096 key, but with only 'OCSP Signing' in 'Extended Key Usage'. When I attempted to upload this certificate I get the same error (in english: 'Certificate authority file may be corrupt').

    I then recreated the cert to include TLS Web Client Authentication and TLS Web Server Authentication, and it uploaded fine as a CA.

    X509v3 Extended Key Usage:
             OCSP Signing, TLS Web Client Authentication, TLS Web Server Authentication

    Finally, I created another cert without the Client Auth flag, and it was also accepted.

    X509v3 Extended Key Usage:
             OCSP Signing, TLS Web Server Authentication

    So I think that the CA validation on upload requires that the Extended Key Usage section of the certificate includes 'TLS Web Client Authentication'.

    How to add this flag will depend on how you created and signed the certificate. I was using openssl and so I had to edit the configuration block in the CA's config file for signing sub-CAs. In Windows CA, you would need to edit the certificate profile used to sign/issue the certificate.

    Update: I also tried creating a certificate with no Extended Key Usage constraints section (similar to the built-in CA file in every device). This uploaded fine as well. So the validation rule is: if there is an Extended Key Usage section, it must contain the Server Authentication flag.

Children
No Data
Unfiltered HTML