For years now, many individuals have been asking to upload their private Secure Sockets Layer (SSL) Certificates to their Network Management Cards (NMC):
Some of these forums are older than a decade of individuals asking how to upload their private SSL certificates. After around of month of talking to support staff and researching the topic, there does not seem to be any resolution to this issue. In my last support case, Jeff Bill said that he would pass my case to the (Presumably Software) Engineers for review. I am creating this thread to show that this change will benefit not only myself but also others that use the Schneider Eclectic array of products. Please reply with why you would be in support of this change.
My Why:Uploading a private SSL to our MNC's will allow for a more cohesive Information Technology (IT) environment. The change will eliminate the annoying security warning that appears when attempting to log into the NMC's and strengthen a security posture within a given IT environment. Because of the versatility of modern SSL certificates (Ex. a Wildcard certificate that covers numerous sub-domains), there is no reason that the NMC should be locked down in this modern era.
My question is, when should we expect to see this change be implemented?
There is a feature request to change the way SSL certificates are handled by the NMC but no clear time frame on its implementation. In the mean time I'd be happy to help you with your issue.
Do you already have a support ticket open, if so can you provide me the case number?
My current issue is that I would like to use an already signed wildcard certificate for our NMC's. What is the next step to proceed? I already tried using the Security Wizard CLI to no avail.
Sorry at present this is not possible, neither pre-signed certificates nor wildcard certificates are supported, you can only use certs that have been created by the security wizard.
The process is you create a CSR and private key with the security wizard, sign the CSR with your internal or corporate CA and finally combine the signed request with the private key using the security wizard.
If you require any help with this process, please let me know.
Is there a way us consumers can see the progress on when that feature will be implemented? Its been a topic of conversation for some time as indicated by some of the posts.
Unfortunately not, even with the request submitted there is no guarantee that it will be accepted and no time-frames are provided. Also this would not be a very high priority request that would require a huge rework in the SSL system.
How long has the request been submitted for? Are there any Service-Level Agreements (SLA) established for support requests and if so, what are those?
Just wondering if you have any update on the SLA requirements on the software development team?
There is no SLA, this is an enchantment request not a support request and not a high priority one as there is currently a way to add certificates to an NMC2.
As I've said previously if you'd like to learn how to use our current tools I'd be happy to help.
Thank you for the offer Gavan, but I have already used the Security Wizard SLI to create a self-signed certificate for our devices. My main goal is to get rid of the annoying security warning when attempting to connect to Network Management Cards (NMC), which could be done with the certificates we purchased.
Does the Network Management Card 3 (NMC 3) have the ability to upload private SSL certificates?
The NMC3 uses the same process as the NMC1 and NMC2.
Have you considered deploying an internal CA, here's a great guide on how to do it with Windows Server: https://www.starwindsoftware.com/blog/using-the-microsoft-certificate-authority-to-get-rid-of-those-self-signed-certs
There is similar guides to do it with Linux and OpenSSL.
I'm also having a problem uploading SSL certificates to my Rack PDUs. It's an essential requirement for me; we aren't permitted to have self-signed certificates in our infrastructure. We also don't really want to use a wildcard certificate or public CA.
I've tried two different ways:
I haven't even managed to get to the point where I can upload the certificate to the PDU. I've got a case open with APC about NMCSecurityWizard, but there doesn't seem to be any way to check the progress.
Looking at how poorly certificates have been handled for a long time now and the lack of progress perhaps it may be worth considering another vendors solution instead.
Hey Scott ,
It does seem certificate management has been and is being handled poorly. We've been looking into solutions from CyberPower and their Remote Management Card. According to their Security Guide, you can upload your own certificate in the PEM format. I feel that APC should allow us to convert our existing certificates into the format that is accepted by their UPS. Come upgrade time and this capability is not met, we'll most likely end our support contract and buy from CyberPower.
Can you tell me what your case number is and I can check its progress?
Can you also try using the following version of Security Wizard:
Please don't post unless your going to try and be helpful, Scott's issue is not the same as yours can can easily be resolved.
Hey Gavan ,
I feel my insights and knowledge are helpful in his or her situation. I provided links and research on products that would work within the environment, as described. A simple key conversion tool or just the ability to supply our keys in the standard format would subside many of the issues I linked and that are within the forum posts.
If my issue is easily solvable, would you be able to tell me how to upload a wildcard certificate to the NMC? When I attempt to upload the certificate, I get an error -32.
That (older) version of NMCSecurityWizardCLI works. You might want to make that more easily accessible!
A note regarding the configuration of the certificates that someone else will hopefully find useful one day - I set keyUsage to keyEncipherment and digitalSignature. Enabling keyAgreement and/or nonRepudiation caused the PDU to get stuck 'Loading certificate...'
Also make sure you have a subjectKeyIdentifier.
I've spent days trying to figure out how to get an SSL certificate to load in our NMCs. Scott's post above helped to put me on a path of enlightenment.
I used the NMC's self-signed certificate as a "MODEL" certificate of what it seemed to be accepting. That's when I noticed the differences that I needed to correct. Mainly the extended key usage definition, and the non-standard "critical" setting on the extended Key Usage and basicConstraints extensions. But the biggest realization is that your CN and alt_names (SAN) has a huge impact on whether the certificate will be accepted or rejected. I'd image this is what most people are having problems with. Since there is absolutely NO error feedback, it's virtually impossible to figure anything out without a LOT of trial and error. Your programmers need to learn how to 1) provide an error message, 2) provide a useful error message when one is given.
I surely hope the information below will help others that are having NMC certificate problems.
Applies to:0M-9631SY (AP9631): APC AOS v6.8.8AP8959NA3: APC AOS v6.8.2
NMCSecurityWizardCLIUtility_v100.zip: 585,444 bytesNMCSecurityWizardCLI.exe: 91,136 bytescl32.dll: 1,181,184 bytes
Example of a working Process:
0. Renamed NMCSecurityWizardCLI.exe to NMC.exe1. Create CSR using NMC.exe:C:\NMCcli>NMC --csr -o symmetra -n symmetra -c US -m Illinois -l Maywood -g "Company Name Inc" -u "Information Technology" -e email@example.com -a 192.168.10.2 -i http://www.companyname.com -d symmetra.companyname.com -k 10242. Renamed symmetra.p15 to symmetrak.p153. Transferred symmetra.csr to internal company CA host4. We use openssl. Using the NMC's self-sign certificate as a "Model" certificate for what the NMC seems to accept, we modified openssl.cnf (in the "[ usr_cert ]" section) so that: a. All Netscape options/extensions were disabled b. ONLY X.509 extensions were allowed, in this exact order: 1. Subject Key Identifier - Entry in openssl.cnf: subjectKeyIdentifier=hash 2. Key Usage - Entry in openssl.cnf: keyUsage=critial,digitalSignature,keyEncipherment 3. Basic Constraints - Entry in openssl.cnf: basicConstraints=critical,CA:FALSE 4. Subject Alternative Name - Entry in openssl.cnf: subjectAltName=@alt_names [ alt_names ] DNS.1 = symmetra.companyname.com DNS.2 = 192.168.10.25. Copy "symmetra.csr" to "/etc/pki/tls/misc/newreq.pem"6. Signed the certificate request: [/etc/pki/tls/misc]# ./CA.pl -sign7. openssl creates a signed certificate and puts it in newcert.pem8. Copy newcert.pem to symmetra.crt9. Copy newcert.pem to ssymmetra.crt (short symmetra.crt)10. Edit ssymmetra.crt to REMOVE the human-readable certificate information BEFORE the "-----BEGIN CERTIFICATE-----" line. The NMCSecurityWizardCLI.exe pukes when trying to create the .p15 file for upload and there is more than just the base64 certificate information present in the certificate file.11. Transfer ssymmetra.crt to Windows machine where NMC.exe exists, and the .p15 private is located when the CSR was created.
12. Create the certificate file for upload to the NMC: C:\NMCcli>NMC --import -o symCERT -s ssymmetra.crt -p symmetrak If successful, you'll get something like: NMC Security Wizard Command Line Utility v1.0.0 (c) Copyright 2018 Schneider Electric. All rights reserved. ----------------------------------------------------------------------------- Certificate's Issuer Information: Common Name: Company Name Root CA Country: US State/Province: IL Locality: Maywood Organization: Company Name, Inc Organizational Unit: www.companyname.com Certificate's Subject Information: Common Name: symmetra Country: US State/Province: Illinois Locality: Maywood Organization: Company Name Inc Organizational Unit: Information Technology Valid From: 08/05/2020 (GMT) Valid To: 08/03/2030 (GMT) Certificate's General Information: Serial Number: 00:CB:45:34:3D:6E:DD:E8:F4 SHA1 Thumbprint: 21:69:81:CE:BB:58:53:C3:A8:EE:1A:8F:14:25:BD:E0:24:A7:5A:93 [*] Importing certificate 'symCERT' has successfully completed. 13. Connect to the NMC Web Interface, and login. Navigate to: Configuration > Network > Web > SSL Certificate Click the "Choose File" button. Navigate to the Windows file where your "symCERT.p15" was created, and "Open" it. 14. The filename will be displayed next to the "Choose File" button. Click "Apply" to load certificate into the NMC. 15. If all goes well, it will only take about 10 seconds for the certificate to load. There is absolutely no good feed back in the browser as to what happens. From extensive testing, I found that 10 seconds usually meant it worked, and 60 seconds meant that it failed.
If successfull, the NMC will immediately start to use it. You should logout and then login to the NMC fully utilize the new certificate.
If unsuccessful, the NMC will take about 60 seconds to regenerate a brand new self-cert and install it, and give control back to theuser. You'll see this if you inspect the cerificate after trying to connect to the NMC after 60 seconds. The cert will only be 2-3 minutesold.
If successful, these will work:https://symmetra.companyname.comor https://192.168.10.2/
This will not work, you get a browser security warning:https://symmetra
Plus you cannot add "symmetra" to the alt_names to get it to work.
This table took quite some time create, but will help to explain what APC support hasn't been able to figure out. When I create certificates, Ilike to be able to use something like:
https://pdu.companyname.comor https://192.168.10.2or https://pdu/
In order to do that, you specify all three as alt_names. But if you use "pdu" as one of the entries for an alt_name, that causes the NMCto REJECT the SSL certificate for some unknown reason.
The APC NMC will also almost always reject the SSL Certificate if you use a FQDN for the CN. There is only one exception to that, and then that is NOT to use ANY alt-names.
This table outlines what works, and more importantly what does NOT work.
Result Test CN AltName AltName AltName=====================================================================================fails PDU1: pdu pdu.dom.com pdu bluepdu.dom.com (2 more)fails PDU2: pdu pdu.dom.com pdu bluepdu.dom.com (2 more)fails PDU3: pdu pdu.dom.com pdu 192.168.10.3loads PDU4: pdu <empty>loads PDU5: pdu.dom.com <empty>loads PDU6: pdu pdu.dom.com loads PDU6b: pdu pdu.dom.com 192.168.10.3fails PDU6c: pdu pdu.dom.com 192.168.10.3 pdufails PDU7: pdu.dom.com pdu.dom.com pdu 192.168.10.3fails PDU7b: pdu.dom.com pdu.dom.com pduFAILS PDU7c: pdu.dom.com pdu fails PDU8: 5A1833E07049 pdu.dom.com pdufails: NMC card fails to load certificate, and generates a new self-signed cert.loads: NMC card loads certificate, and immediately starts to use it inabout 10-15 seconds
Hopefully, APC will make this a less painful process. I wonder how many man-hours have been wasted trying to get a working certificate on a APC device.
Interesting; I was able to get my NMC to accept a certificate that had the non-FQDN name as a SAN.
I created a script that automates it for me, happy to share the steps I used later on when I'm back at my PC.
So today I rolled out certificates to all my Rack PDUs (NMC2 AP9538 v6.8.2) and all worked fine with CN as FQDN mypdu.mydomain and SAN with FQDN mypdu.mydomain and hostname mypdu.
I also needed to put a certificate on a SmartUPS (NMC2 AP9631 v6.8.8) as well - and that didn't work. It accepted the certificate as valid (and if you connect via HTTP the SSL cert menu shows the certificate as valid, with it's details) but HTTPS is now broken and I'm no longer able to connect.
No difference in the process for generating them at all.
I'll try tomorrow leaving off the SAN completely, but this already means that different processes/certificates work for different devices which is terrible!
If it helps anyone, here's what I did for my Rack PDUs using the version of NMCSecurityWizardCLI above (v1.0.0):
Create config file: mypdu.cfg containing:
basicConstraints = CA:FALSEextendedKeyUsage = serverAuthkeyUsage = keyEncipherment, digitalSignaturesubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuersubjectAltName = DNS:mypdu.mydomain, DNS:mypdu
Then run the following commands:
NMCSecurityWizardCLI --csr -o mypdu-csr -n mypdu.mydomain -c GB -m England -l County -g Org -u Dept -e contact@mydomainopenssl x509 -req -in mypdu-csr.csr -CA myca.crt -CAkey myca.key -CAcreateserial -out mypdu-cert.crt -extfile mypdu.cfg -days 3650
NMCSecurityWizardCLI --import -o mypdu-apc -s mypdu-cert.crt -p mypdu-csr
This gives you a mypdu-apc.p15 file that works with the Rack PDUs.
Hey Gavan ,Still wondering if you can resolve my issue. How am I able to upload a pre-signed wildcard certificate to my NMC?
I look forward to your response.
As I've already stated pre-sign certificates are not supported nor are wildcard certificates. This is not going to change in the near to medium term.
Yes, you did state that before, but now I'm confused. You said my problem could be easily resolved, what are you referring to?
Choose a location