SSL certificates supporting multiple IPs and names (SAN)

[Xavier Walker]

After struggling to get basic SAN-style certificates for the Onboard Administrator, but eventually succeeding, I've now moved onto trying to sort out SSL certificates for our VC modules.

However, it appears that the CSR the VC modules produce do NOT invlude the alternative names, even though they are defined in the web page.

The resulting certificates do not contain Alternative Names in them, so the web browser still complains.

My chassis are running with OA firmware 4.85 and all VC modules (I have a mixture of Ethernet and SAN) have all been updated to firmware 4.63.

I can only imagine this is a bug, but a pretty serious one!

Thoughts?

[MV3]

Hi,

Good day!

Below is the User guide for HPE Virtual Connect for c-Class BladeSystem User Guide Version 4.63 . Please refer to the same and check if the ssl certificate is generated accordingly.

https://support.hpe.com/hpsc/doc/public/display?sp4ts.oid=4144089&docLocale=en_US&docId=emr_na-a00055965en_us&withFrame

Review the Managing SSL configuration page @ page number 54.

Cheers

[Xavier Walker]

Hi Mv3,

Thanks for your post and link to the documentation.

Yes, I am following this. The issue seems to be that the fields entered into the "Alternative Name" section aren't actually used in the CSR so the resulting certificate doesn't contain them.

I'm not on site this week to check, but will confirm next week.

[Steve_Tippett]

From my research, the Alternative Name fields are not checked properly - it's unclear if that is a browser issue (I'm using Firefox) or Virtual Connect isn't sharing the values from the Alternative Name fields, which are visible in the CSR screen of the GUI and in the proper format, which is "IP:1.2.3.4,DNS:fully.qualified.domain.name".  My issue is, I get the browser pop up for "Bad Certificate domain" when I browse to the IP address listed in the Alternative Name field.

[Xavier Walker]

I've had another play with this and can confirm the Virtual Connect certificates do NOT work properly with SAN. Only the Common Name is taken into account, and any data entered into the Alternative Name is simply ignored.

This is in contrast to the Onboard Administrator units where the Alternative Name field does work and so I'm able to generate certificates that work for both IP, short DNS name and FQDN.

This is a real annoying limitation on VC which really should be looked at.

[LarsPx]

I am experiencing the same very annoying behavior; when generating the CSR on the (version 4.63) VC, only the CN and none of SAN entries seem to make through to the certificate. The SAN entries seem to be present in the CSR (if you base64 decode the CSR), but not correctly entered and subsequently ignored at certificate generation.

I do not have this problem when creating certificates for our Onboard Administrators.