Open Stack

Hi,

I think that the discussion have asked that obtaining information out of the x509 via the SAN field will not be defined as mandatory.

For example Radware's backend extracts this information from the x509 in the (virtual) device itself, specifying dns values different than what exists in the x509 is not relevant.
I think that NetScaler case, is similar with the exception (if I understand correctly) that it does not extract the values from the SAN field. Also in this case, if the front end will provide the domain name outside the x509 it will not matter.

Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code.

-Sam.



From: Eichberger, German [mailto:german.eichberger at hp.com]
Sent: Tuesday, July 15, 2014 6:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

Hi,

My impression was that the frontend would extract the names and hand them to the driver.  This has the following advantages:


*         We can be sure all drivers can extract the same names

*         No duplicate code to maintain

*         If we ever allow the user to specify the names on UI rather in the certificate the driver doesn't need to change.

I think I saw Adam say something similar in a comment to the code.

Thanks,
German

From: Evgeny Fedoruk [mailto:EvgenyF at Radware.com]
Sent: Tuesday, July 15, 2014 7:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

Hi All,

Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision.
Currently, the document says:

"
For SNI functionality, tenant will supply list of TLS containers in specific
Order.
In case when specific back-end is not able to support SNI capabilities,
its driver should throw an exception. The exception message should state
that this specific back-end (provider) does not support SNI capability.
The clear sign of listener's requirement for SNI capability is
a none empty SNI container ids list.
However, reference implementation must support SNI capability.

Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames
from the certificate which will determine the hostname(s) the certificate
is associated with.

The order of SNI containers list may be used by specific back-end code,
like Radware's, for specifying priorities among certificates.
In case when two or more uploaded certificates are valid for the same DNS name
and the tenant has specific requirements around which one wins this collision,
certificate ordering provides a mechanism to define which cert wins in the
event of a collision.
Employing the order of certificates list is not a common requirement for
all back-end implementations.
"

The question is about SCN and SAN extraction from X509.

1.       Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake

2.       Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host

Please give your feedback

Thanks,
Evg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/bd89d8a8/attachment.html>