Bug 1326385 - IP SANs are not added to host certificates when an IP address is used
Summary: IP SANs are not added to host certificates when an IP address is used
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: PKI
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: ---
: ---
Assignee: Itamar Heim
QA Contact: Pavel Stehlik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-12 14:50 UTC by Roman Mohr
Modified: 2016-04-14 07:31 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-14 06:46:07 UTC
oVirt Team: Infra
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

Description Roman Mohr 2016-04-12 14:50:08 UTC
Description of problem:

From the engine created host certificates have no 'subjectAltName' set when the IP address is used to communicate with the host. Recent TLS libraries like the golang TLS library fail with an error like

> Failed to tls handshake with x.x.x.x x509: cannot validate certificate for x.x.x.x because it doesn't contain any IP SANs

when trying to connect to VDSM. To work around that the host verification needs to be disabled completely on the client side.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Add a host to the engine and connect to it using an IP address
2. Install the host or roll out new certificates
3. Try to connect via TLS to VDSM by using a valid client certificate
4. The client can authenticate to the server but the server can't be verified with strict libraries

Actual results:

When using IPs to connect to hosts from the engine we roll out certificates which do not have the 'subjectAltName' set. This means that in this case you have to disable the host verification completely to connect to VDSM.

Expected results:

When an IP is used for connecting to hosts we should could add something like 'subjectAltName=IP:192.168.7.1' to the certificate.

Additional info:

Comment 1 Oved Ourfali 2016-04-14 06:46:07 UTC
As this is a corner case, and the guideline is to use the FQDN rather than the IP, I'm closing this as WONTFIX.
Enterprise users and customers will never use IPs, same goes for most smaller deployments.

Comment 2 Roman Mohr 2016-04-14 07:31:33 UTC
(In reply to Oved Ourfali from comment #1)
> As this is a corner case, and the guideline is to use the FQDN rather than
> the IP, I'm closing this as WONTFIX.

That you should use FQDNs in production is out of question but we do

1) not prohibit users from entering IPs
2) not warn them when they do that
3) use it a lot during development
4) use it a lot in presentations .

> Enterprise users and customers will never use IPs, same goes for most
> smaller deployments.

I see no reason not to use IPs when I just run let's say 3 hosts. When I will ever have to change my IPs I just add them again.

I would give it low priority and just do the small fix but closing it does not seem right.


Note You need to log in before you can comment on or make changes to this bug.