Unable to import SSL certificate

[pgpc_apc]

I have been struggling to import an external CA SSL certificate into NMCv2 since 2018 prior to the NMCSecurityWizardCLI.  Our CA was then running under Windows Server.  It now is running OpenSSL.

I am encountering the same errors as reported by many others in trying to import the OpenSSL CA-signed certificate.  I am using NMCSecurityWizardCLI v1.0.0 to create the CSR, our internal OpenSSL CA to sign it with a SHA256 hash and NMCSecurityWizardCLI v1.0.0 to import the signed certificate, all meticulously in accordance with the instructions in the readme file and the instructions in APC's Network Enabled Devices Security Handbook.  If I try to import the entire .crt file generated by OpenSLL, signed certificate, NMC has an unrecoverable error:

Unhandled Exception: cryptlib.CryptException: -32: Bad/unrecognised data format
at cryptlib.crypt.ImportCert(Byte[] certObject, Int32 certObjectOffset, Int32 certObjectLength, Int32 cryptUser)
at cryptlib.crypt.ImportCert(Byte[] certObject, Int32 cryptUser)
at NMCSecurityWizardCLI.Program.ImportSignedCSR(String sCertFile, String sKeyFile, String sOutFile)at NMCSecurityWizardCLI.Program.Main(String[] args)

If I extract the Base64 certificate from the .crt file and try to import just that, NMC has a different unrecoverable error:

Unhandled Exception: cryptlib.CryptException: -3: Bad argument, parameter 3
at NMCSecurityWizardCLI.Program.ImportSignedCSR(String sCertFile, String sKeyFile, String sOutFile)
at NMCSecurityWizardCLI.Program.Main(String[] args)

In a post in this string ,https://community.se.com/t5/APC-UPS-Data-Center-Enterprise/bd-p/datacenter-forum, Gavan gave a link to a guide with steps to follow to solve the -32 bad format problem, but the link does not work now.

That some have reported success in importing OpenSSL CA-signed certificates suggests APC's instructions are missing critical information necessary to use it successfully.  I would appreciate APC either identifying the problem from the error messages above or a providing a complete set of instructions.  If someone who has successfully imported an OpenSLL CA-signed certificate would post a copy of the applicable portions of their openssl.cnf file, I would be grateful.

[Anonymous user]

I successfully imported my OpenSSL CA certificate using the web UI. you just need to rename the file extension from pem to crt, then it should work.

However! Sending mail vie SSL implicitly or with StartTLS does not anyway! This works if I use a Lets Encrypt Certificate on the server, but my own self-signed CA certificate is not accepted, although I uploaded it and enabled it for Email use...

[Anonymous user]

To be more explicit, this method onyl works for the SMTP SSL/TLS root CA certificate!

For HTTPS the UI expects a p15 file and the only software able to generate that is the APC Security Wizard for Windows. To be honest, this is really appalling. APC shoudl be able and willing to provide the posibility to upload openssl file formats without the need for a proprietary tool to convert the files before upload. We are in 2021, how hard can it be? This is a problem since so many years now!

[pgpc_apc]

It turns out that APC cleverly labeled the buggy v1.0.1 of NMCSecurityWizard as v1.0.0 to cause even more frustration and confusion.  After stumbling on to the deception, I obtained the true v1.0.0 from Tech Support and, as others have reported, it works. 

Be aware the zip file on APC's web site labeled "NMCSecurityWizardCLI_v1.0.0" does not actually contain NMCSecurityWizardCLI.exe v.1.0.0 despite the included executable's properties showing it to be "Product Version 1.0.0.0" and "File Version 1.0.0.0".  When the executable is run, it reveals it is actually "NMC Security Wizard Command Line Utility v1.0.1," which is further confirmed by the fact that it will not import a signed certificate. 

The zip file that does contain NMCSecurityWizardCLI.exe v1.0.0 is labeled "NMCSecurityWizardCLIUtility_v100" and it is available from Tech Support.  The properties of the executable in this zip file show are identical to those of the imposter, i.e., "Product Version 1.0.0.0" and "File Version 1.0.0.0," but when running it reports it is truly is "NMC Security Wizard Command Line Utility v1.0.0.

The SHA-1 hash of the true v1.0.0 is: 017056A6296DB11FEE69F970FC34EBD81F31891B.  The SHA-1 hash of the imposter is: 0F0A54979CB9F15208D3175CF0E9B1F5FDB65ADB.

Two tips for those using OpenSSL that I had to learn by trial-and-error:

1.  Although not stated anywhere in APC's documentation, the certificate to be uploaded must be just the Base64 portion of the .crt file that OpenSSL generates.  

2. The NMCSecurityWizardCLI utility generates CSRs with the data you enter (i.e., countryName, organizationName, etc) encoded as PRINTABLESTRINGs.  If your CA is set up with a utf8only string_mask and your openssl.cnf includes a policy requiring a match between any of the entered CSR data and the CA's details, such as requiring a match for the organizationName, as mine is, OpenSSL will refuse to sign the certificate and complain of a mismatch between the CA's organizationName and the CSR organizationName:  "The organizationName field is different between CA certificate (Example, Inc.) and the request (Example, Inc.)."  This is because OpenSSL compares the encoded data instead of the underlying data so that it treats UTFSTRING-encoded Example, Inc. as different from PRINTABLESTRING-encoded Example, Inc.  The work around is to revise your openssl.cnf to change the policy from "match" to "supplied" for any of the data you supply in the NMCSecurityWizardCLI-generated CSR.

[Anonymous user · Accepted solution]

the overall bottom line is, that for the cost of these devices it is appalling how few development they spend on modernizing their software. this is how companies or branches go extinct.