Faulty alternative name in CSR from OneView

[Radapompa]

Hi,

I created a new CSR in OneView and had it signed in our own PKI. The certificate was sucessfully imported back to OneView and we could use it. But for some reason, Firefox complains that the alternative domain name is not in the certificate. It works fine in Chrome, IE and Edge.

So after some more digging, we believe that it may be due to that OneView is not generating the CSR in the correct way.

By default, you have the IP address and name of the appliance in the Alternative Names field when you want to create a CSR. Which is fine. But when you have created the CSR with this, it will create two fields for the ip address in the Alternative Names field in the CSR. One which is an IP address, and one which is a DNS name.

As an example. IP address for the appliance is 10.1.1.10, and the name is oneview.example.com. The names in the alternative names field in OneView would then be:
10.1.1.10,oneview,oneview.example.com

When creating the CSR, these are the fields that would end up in the Alternative Names section:
DNS-name: oneview.example.com
IP-Address: 10.1.1.10
DNS-name: 10.1.1.10
DNS-name: oneview

So the issue here is that it creates the DNS-name field that contains the IP address. This was tested in version 4.10.4-0370820.

Can someone confirm that this happens for them aswell?

[BhaskarV]

Hi @Radapompa

Thank you for bringing this up.
With Firefox Quantum 64.0 version that I just tested with, I dont see the error you are describing.
I used the default CSR from OneView.
The alternate names I have in the signed certificate look like the below.

Not Critical
DNS Name: test.hpe.com
IP Address: 1010.10.10
DNS Name: 10.10.10.10
IP Address: fe80::4211:7deb:405c:e9b9
DNS Name: fe80::4211:7deb:405c:e9b9
DNS Name: [fe80::4211:7deb:405c:e9b9]
DNS Name: test

What version of firefox are you using?
Did the CA that signed the certificate put in the same exact FQDN in the SAN field for DNS Name:? 

Possibly you can share sanitized / modified field values from the SAN field and how you access the appliance i.e. the URL.

Or open a support case about this;

We will anyway correct the DNS-Name: <IP address> 
It is incorrect but should be harmless.

I work for HPE.

[Adis_S]

Did you enabled to use Default Windows Client Cert store in your Client (if you use Windows)?

Firefox parameter:

security.enterprise_roots.enabled

Anyway if accessing server by using it's IP Address and using the IE11 Browser and have Certificate without DNS=IPAddress, then IE11 will see server's certificate as not trusted, HPE wrote me that this is bug in IE, Firefox for example works without this DNS=IPAddress but I have activate that Firefox parameter above.

I wrote aboute missing DNS=IPAddress for iLO4/5 here
Add SAN and ignore IPv6 to Start-HPEiLOCertificateSigningRequest

[Radapompa]

Hi Bhaskar,

Thanks for looking into this. Great that you will fix the DNS name: <ip address> issue.

Regarding the issue with Firefox. Did you test both DNS names in the certificate? In my case, I'm trying to use a DNS name that is after the IP address entries, and that one is failing. The first one that is before the IP addresses works fine.

So in your certificate. https://test.hpe.com would work fine. But https://test won't (even if it resolves correctly to the ip address). Could you confirm this?

So I believe that Firefox can't handle entries below an DNS name: <ip address> entry. And that is why I see this issue.

[Radapompa]

Hi Adis,

I had the root certificates in the Firefox certificate store. So there isn't an issue with that. But thanks for the tip with enabling Default Windows Client Cert Store. Didn't know that Firefox could do that.

[BhaskarV]

Hi @Radapompa

Thank you for sharing that.
Yes, I do see a problem with Firefox accessing https://<short hostname> 
Will figure out what is going on and come back.

Regards,
Bhaskar

[Adis_S]

I don't have such issue here with Firefox and iLO (changed there the HPE Selfsigned Certificate with our internal CA)

Firefox Quantum ESR 60.2.2esr (32B-Bit)

https://shortname
https://fdqn
https://ip

All three above request are working fine.

Our Certificate have following SAN:

DNS-Name: fqdn
DNS-Name: shortname
DNS-Name: 1x.x.x.4
IP-Adresse: 1x.x.x.4

[BhaskarV · Accepted solution]

Thanks @Adis_S

Hi @Radapompa -
Acknowledging the problem with the default CSR generated by OneView.
It turns out that the ordering of the entries in the SAN matters to firefox in paritcular.
Seems to be validated by what @Adis_S has shared as well.

Firefox does not read DNS and IP address entries in the SAN beyond the first one with IP address: 

A CSR / signed-certificate that Firefox will like, will look like:

SAN:
DNS: FQDN
DNS: alias to FQDN
DNS: alias to FQDN
DNS: short hostname
IP: IP address 1
IP: IP address 2
IP: IP address 3

A CSR / certificate that Firefox does not like will have DNS / IP addresses not grouped together but mixed up like the below:

SAN:
DNS: FQDN
DNS: alias to FQDN
IP: IP address 1  <= Firefox does not read the DNS: entries below this line.
DNS: alias to FQDN  <= all entries starting this one and below are ignored and not honored by Firefox
DNS: short hostname
IP: IP address 2
IP: IP address 3

We will revisit the ordering of these fields in our default CSR and correct them.
Thank you so much for bringing this up and sharing with us.

Even though the CSR has the fields mixed up in order, at the time of requesting a CA signed certificate as well as at the time cerificate signing, the CA has full control over over-riding / specifying the SAN entries entirely.

We'll correct both problems:
1. DNS; <IP address>
2. Ordering . grouping of DNS: entries together first followed by IP: entries next in the SAN.

Regards,
Bhaskar