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
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
OpenStack-dev mailing list