7 years later I would like to revive the discussion of support for intermediate certificates.

With AOS 6.2 and Security Wizard Version 1.04 intermediate certificates are still not supported.

By now every major CA is using intermediate certificates and the lack of support for them by AOS essentially prevents the use of any certificate issued by any well known CA.

I haven't seen any questions arise related to this issue. I have generated my own certificate and had it signed by a CA authority and have been able to access using both IE and Firefox, but am not familiar with the intermediate certificate requirements. Who is the CA that is generating the certificate, Digicert? From browsing through some of the methods for these other applications on the link you provided, it appears as if the intermediate certs are appended to the single .crt file. Have you tried appending the intermediate certs to the main cert before using the APC security wizard Import Signed Certificate function?

Thanks for the reply. The CA I'm using is GlobalSign, using their Cybertrust Educational subsidiary, although I don't think the actual CA is important. I couldn't find any helpful public pages on the GlobalSign site, so I gave the link to the help pages on the Digicert site instead, because they explained the problem better.

I have also been told by my CA to install the "GTE CyberTrust Global Root" certificate at http://secure.globalsign.net/cacert/ct_root.pem and the "Cybertrust Educational CA" certificate at http://secure.globalsign.net/cacert/sureserverEDU.pem onto the web server, in addition to the site certificate.

If you follow those links you'll see that the first one has some human-readable stuff following by the -----BEGIN CERTIFICATE-----/-----END CERTIFICATE----- section, while the second link just includes the -----BEGIN CERTIFICATE-----/-----END CERTIFICATE----- section. In all cases where I've tried to use ct_root.pem I've just used the -----BEGIN CERTIFICATE-----/-----END CERTIFICATE----- section, as I'm assuming the human-readable bit isn't supposed to be imported.

As you said, for some web servers the solution is to concatenate all the certificates into one text file before loading onto the web server. I have tried that with the APC Security Wizard with no luck so far.

I have tried putting the site-specific certificate first, followed by the ct_root.pem then sureserverEDU.pem, and I've also tried putting the site-specific certificate first, followed by the sureserverEDU.pem then ct_root.pem. In both of those cases it seems the Security Wizard just ignored the second two certificates as if they weren't there - in other words, the result was exactly the same as if I just had the site-specific certificate in the file.

If I put either sureserverEDU.pem or ct_root.pem first in the concatenated text file, the Security Wizard gives a message "Error Adding Key , code: -2".

My guess is that the Security Wizard expects to see the site-specific certificate first in the text file, and when it reaches the end of it, it ignores the rest of the text file. If it sees anything before the site-specific certificate it throws an error.

Surely I can't be the only one in this situation. The reason I'm using this particular CA is that we have a very cheap educational deal on certificates, so I don't want to try another CA. And anyway, as far as I know most CAs require these intermediary certificates to be installed on web servers these days.

John,

Currently APC NMC devices do not support SSL Certifcate Chaining. This may be considered for future revisions of the Card and/or Card firmware, however it is not planned for any revision in the near future.

I posted about this in the "Can't import SSL Cert to Management Card" thread, but thought I should start a new thread rather than hijacking someone else's.

I'm trying to setup secure HTTPS access to my Network Management Card (NMC). My goal is to be able to connect to the NMC securely from any mainstream web browser (IE, Firefox, Opera, Safari), on any machine, including machines upon which I don't have administrative access (e.g. Internet cafes) so cannot install browser certificates. I want to be able to trust that I am really connecting to my own NMC, so that noone is intercepting the password etc.

This means that I need to install a real SSL certificate, issued by a CA (certificate authority) recognised by mainstream browsers, rather than a self-signed certificate or one signed by an in-house CA.

I have got as far as using the APC Network Security Wizard 1.02 to generate the CSR (certificate signing request), sending it to my CA, receiving the signed .crt file back, and importing that into Network Security Wizard. I can then upload the resultant .p15 file to the NMC.

The problem is that I also need to install so-called 'intermediate' or 'chaining' certificates onto the web server, in this case, the NMC built-in web server. This is, as far as I understand, a very common issue with certificates issued by most CAs these days. The intermediate certificates on the web server make sure that the certificate presented to the browser has the correct chain of trust. If the intermediate certificates are not installed on the web server, many web browsers will complain that it cannot trust the certificate presented to it.

Both Firefox and Opera require the intermediate certificates to be installed on the server. Strangely IE and Safari do not, but I believe this is a lack of security in IE and Safari rather than a bug in Firefox and Opera. The correct thing for a web server to do is to present the complete chain of trust.

The following link http://www.digicert.com/ssl-certificate-installation.htm is from a different CA than the one I'm trying to use but explains the problem quite well. You'll notice that it gives instructions on how to install the intermediate certificates on several different web servers, not including the NMC web server.

So my question is, is there a way to install intermediate certificates onto the NMC web server?

Note that I cannot simply install the intermediate certificates into the browser, as I'll be using lots of different browsers on lots of different machines, some of which might have a tied-down configuration. The whole point of installing a 'real' certificate was to try and stop any popup warnings on web browsers and give a secure connection. Anything other than having the web server present the intermediate certificates as it should is a kludge.

Indeed a serious failing.

Ironic that the APC SW utilities like PCNS provide an "accept insecure certificate" option, but cannot actually create a secure configuration for such a large percentage of the major certificate authorities operating today. My understanding is that without an intermediate cert, the "master" CA certificate is at greater risk of compromise, which is why so many CA's don't do it that way any more today.

Looks like the cards are mostly going to have to be used either with the self-signed cert, or with an internal/organizational CA. (Which of course also requires installing the organizational CA's root cert on all browsers that need to manage the devices)

I use an internal CA on all of my devices. The whole SSL thing on the APC devices needs a big overhaul - not only does nobody else accept their .p15 files, but you'll find (if you spend the time to track it down) that their .p15 files themselves are non-standard.

I assume this was to provide some sort of partially-digested pablum to the cards, since the cards don't have a lot of CPU power. However, it does break a large number of other things, including wildcard certificates (and any other certificate issued for the device where there was no corresponding request via the Security Wizard). Using standard PEM format almost always allows the user to concatenate the intermediate certificate and feed it to the device which is then happy.

With all the recent revelations about various SSL/TLS vulns, I'm a little afraid to even check into which ciphers, hashes and key lengths the new cards support. The older cards only support RC4 and DES/3DES ciphers, insecure hashes like MD5 and SHA1, and 768-bit key length. 

Not something you'd want to put on the internet without at least a firewall in front of it with access control. (Which still won't help if you don't want people capturing your sessions and credentials.)

The newer cards (at least with the latest 6.2.1 firmware) support TLS 1.1 (which isn't ideal as TLS 1.2 would be better). Both the old and new cards support 1024 bit (although at least the older ones generate 768 when they self-sign). I'm almost positive the newer cards support 2048.

Per this thread, updated SSL support for some of the older NMC2-based devices is being actively worked on. Unfortunately, the various browsers have morphed from "how secure can we be and remain compatible?" to "is there an award for breaking the most stuff?" which makes this SSL stuff very much a moving target.

This is all hard to tell from the Security Wizard, since it is the same old one from 2010 still. And the older cards (not sure about the newer ones) don't give any indication that a certificate you uploaded via the wizard is defective - the card either retains the old certificate with no warning, or deletes the old certificate and doesn't install the new one, depending on some mysterious conditions. 

So after 12years, still unable to get a key and csr from the UPS web interface in order to use our ADCS PKI infrastructure...

Tried using the APC Security Wizard 1.04 by creating a csr, signing it with ADCS and back into the wizard...

but still does not work ! Anyone found a way to set these web interface in https using your interface ADCS CA's & sub ca's ?

Thx

You are not alone.

I am trying to get an SSL cert into this AP8641, the .p15 was never used by anyone I know, maybe some obscure ID Card company with non-standard 7641 cards...  Still, if an arduino can use SSL, I can't imagine it would be hard for APC/Schneider to update their library.  It's the same issue with DCE/DCO software, they support TLS but the first check to validate the version number is an SSL 1.0 request and it's being blocked by all reverse proxies and firewall.  One request to bring them all down, almost sounds like a ring doesn't it?

Well, I am using the Security Wiz 1.04.  I finally realized the thing generates a private key when it does the .CSR file.  I generate my .cer with my MS ADCS service setup as an Enterprise CA.  I keep getting Error importing cert., code -32.

Could you be more obscure as to the issue please, the error message is still clear enough to know it's an error !  ;-)  

Maybe a description of what the error is, could be useful?  Also, in the CSR wiz, please specify which key and files you are talking about, an existing file to be provided or a file that will be created, it's source, content, use.  I wasted a few hours just on that, for a question of language.  If you need, I can help, I speak it even though I am a native french speaker.  I'm told I am quite proficient too.

A simple white paper on this wouldn't hurt.  Or a few pages and links in the manuals.  FAQ with HTTPS, SSL, TLS, Encryption, Secure Web Page, P15, public / private key, Certificate, Digital Certificate...  I can keep giving search tags for at least a page full on the subject.

It's a simple process, and many free and available exiting, tested library and up to date code is available.  With proper make files, easy to upgrade and test.  Just sign up for newsletter updated on the git repo or which ever repo the code sits.  Easy-peasy...

</Frustrations>

So please, pretty please with sugar on top, could you, in plain english, describe a way to generate a key for your devices with examples and in your case, you need to include restriction and madatory information to include in the CSR, what can and cannot be added.

My personal case, I need to add san=dns=mypdu.domain.bob@dns=mypdu&ipaddress=192.168.12.12

So if someone goes to https://mypdu.domain.bob/    https://mypdu/  or  the dreaded https://192.168.12.12/  they will have a perfectly acceptable site coming up without any warnings and it will be SSLed, TLS'd and happy.

I do have a ticket opened with Support, created on the web a few hours ago.  Fell free to call on me, I have very very familiar with digital certificates, https, and many many many many other subjects of the kind.  I play a lot with my Raspi and arduino so I'm not affraid of IoTs...

Let's encrypt !!!  and be happy for ever more.

</rant>

Marky Marc !

Ouch!

So I figured I was asking for too much for SAN support.

Process,

I used the Wiz 1.04.  create a basic CSR, all uppercase, no spaces.  Real 1970 like.

Ran it thru my trusting Enterprise CA, using Web Template, plain jane, as if it was the 80s.

Downloaded the .CER and the p7b just for the kick of it (not going to be used anyway...).

Run the Wiz 1.04 again, this time import, I feed the .CER, .p15 (private key it generated at the same time as the .csr) and named my resulting .p15.  all with no spaces or punctuation.  Just like on a good ol' Mainframe, Dec PDP-11 (I know I used one during my college days), all CP/M like, DOS 1.10 all the way ;-) not taking a chance here.

Guess what . . .  eheheh...  you get a second chance...  Error -32 !  Yep that's right.  It did not work.

I am really sad about this.  2 hours more in the ditch.

Marky Marc

<waiting_praying_bleeding_for_support_;-)_okay_lots_of_teasing_too>

Hopefully, some of you reading this will chuckle a bit, at least.  We will get resolution !

Hey all,
Because installing private SSL's on NMC is a reoccurring theme, I decided to create a discussion after some progress was made during a support chat.

https://forums.apc.com/spaces/7/ups-management-devices-powerchute-software/forums/general/95305/uploading-private-ssl-certificates