[WFLY-19269] [Preview] OCSP stapling support #564
Conversation
| # Add any category for this proposal | ||
| # if missing, add it to _data/widfly-categories and use its id | ||
| --- | ||
| = [Experimental|Preview|Community|default]Template <INSERT TITLE HERE> |
There was a problem hiding this comment.
I think we can go with Preview for now. The title here should be updated too along with the PR title.
| :idseparator: - | ||
|
|
||
| == Overview | ||
| Online Certificate Status Protocol (OCSP) is one of the methods of checking whether or not a certificate presented by a client is valid or not. It is a protocol for determining the status of a certificate and is described in http://www.ietf.org/rfc/rfc2560.txt[RFC 2560]. |
There was a problem hiding this comment.
s/certificate presented by a client is valid or not/certificate is valid or not
|
|
||
| === Issue | ||
|
|
||
| * https://issues.redhat.com/browse/WFCORE[WFCORE-XXXX] |
There was a problem hiding this comment.
Since this will involve updates to the Elytron subsystem, we'll need a WFCORE issue to be created and linked here.
There was a problem hiding this comment.
I have added the WF-Core issue.
| == Requirements | ||
|
|
||
| === Hard Requirements | ||
| * Existing OCSP support for WildFly's Elytron subsystem would be extended to allow for OCSP stapling. A new attribute, called `enable-stapling`, would be added to `elytron/key-manager` to allow for stapling support. |
There was a problem hiding this comment.
The existing OCSP support is part of the trust-manager configuration. For that, we are configuring details about the OCSP responder that the server will use when trying to determine if the certificate presented by the client has been revoked.
However, OCSP stapling is something that will be used by the server to staple the response from the OCSP responder to its own certificate that it will present to the client. So this new configuration should be separate from the server's trust-manager configuration.
This line mentions key-manager but the sample configuration below shows the trust-manager so maybe it's just the sample config below that needs to be updated?
There was a problem hiding this comment.
I have updated the server-side proposals to add to the key-manager resource instead of the trust-manager.
|
|
||
| ** This attribute would be of type boolean. To allow for backwards compatibility, this attribute's value would be false by default, which would allow for traditional OCSP support. | ||
|
|
||
| Current Subsystem Configuration: |
There was a problem hiding this comment.
Take a look at https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/ocsp.html#ocsp-stapling-and-certificate-revocation.
This explains OCSP stapling and system properties that can be used to enable it/configure it. This will be helpful to determine the types of things that could be added to the configuration.
There was a problem hiding this comment.
When a WildFly server is acting like a client (e.g., via client-ssl-context configuration), it should be able to make use of the OCSP response stapled to the certificate returned by the server its communicating with.
There was a problem hiding this comment.
Updated the new attributes based on the protocol information in the link above. Thanks for sharing it.
| === Hard Requirements | ||
| * Existing OCSP support for WildFly's Elytron subsystem would be extended to allow for OCSP stapling. A new attribute, called `enable-stapling`, would be added to `elytron/key-manager` to allow for stapling support. | ||
|
|
||
| ** This attribute would be of type boolean. To allow for backwards compatibility, this attribute's value would be false by default, which would allow for traditional OCSP support. |
There was a problem hiding this comment.
The existing OCSP support is for the server's trust-manager so this would be separate from OCSP stapling.
| <trust-store key-store-name="ca"/> | ||
| <trust-manager algorithm="PKIX" maximum-cert-path=4 soft-fail="true" only-leaf-cert="true"/> | ||
| <certificate-revocation-list path="crl.pem"/> | ||
| <ocsp responder="responderUri" enable-stapling=true responder-certificate="certalias" responder-keystore="responder-store"/> |
There was a problem hiding this comment.
For the client configuration, the client needs to be able to make use of the OCSP response stapled to the certificate that's being presented by the server.
There was a problem hiding this comment.
New client config is TBD.
I will look more into what needs to be defined and will update client side proposal.
PrarthonaPaul
force-pushed
the
EAP7-1580
branch
from
af5500c to
c73003b
Compare
| # Add any category for this proposal | ||
| # if missing, add it to _data/widfly-categories and use its id | ||
| --- | ||
| = [Preview] OCSP Stapling Support |
There was a problem hiding this comment.
Please update the PR title as well, thanks!
| ** `cacheLifetime` which controls the maximum lifetime of a cached response in seconds. The default value is 3600 s or 1 hour. | ||
| ** `responderURI` which is the responder to contact in case the certificate used by the server does not have the `Authority Info Access` (AIA) extension. This does not override the AIA extension value unless `responderOverride` is set to true. The default value for this is undefined. | ||
| ** `responderOverride` which determines whether or not the Authority information from the AIA extension value would be overridden by the value of the `responderURI`. The default value for this is false. | ||
| ** `ignoreExtensions` which determines whether the forwarding of OCSP extensions specified in the `status_request` or `status_request_v2` TLS extensions is disabled or not. The default value for this is false. |
There was a problem hiding this comment.
A - is being used in some attribute names but not all. We should be consistent.
There was a problem hiding this comment.
It would be good to indicate if any of these attributes are required or if they are all optional.
There was a problem hiding this comment.
updated all attributes to use - and all lowercase.
| == Requirements | ||
|
|
||
| === Hard Requirements | ||
| * Existing OCSP support for WildFly's Elytron subsystem would be extended to allow for OCSP stapling. A new attribute, called `ocsp-stapling`, would be added to `elytron/key-manager` to allow for stapling support. Additionally, this attribute would have the following attributes nested under it: |
There was a problem hiding this comment.
This would be a new element with attributes (as opposed to "attribute would have the following attributes under it").
There was a problem hiding this comment.
Thanks for the comments!
This resource (https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/ocsp.html#ocsp-stapling-and-certificate-revocation) has the following blurb under Server-Side Properties.
"Most of the properties are read at SSLContext instantiation time. This means that if you set a property, you must obtain a new SSLContext object so that an SSLSocket or SSLEngine object you obtain from that SSLContext object will reflect the property setting. The one exception is the jdk.tls.stapling.responseTimeout property. That property is evaluated when the ServerHandshaker object is created (essentially at the same time that an SSLSocket or SSLEngine object gets created)."
This makes me think, would the new element and attributes be better added to SSL-context instead of key-manager?
What do you think?
There was a problem hiding this comment.
Ok, awesome. Thanks!
I have added these attributes under server-ssl-context and updated the proposed configuration
PrarthonaPaul
changed the title
PrarthonaPaul
force-pushed
the
EAP7-1580
branch
from
c73003b to
e6cecf6
Compare
PrarthonaPaul
force-pushed
the
EAP7-1580
branch
from
e6cecf6 to
8432479
Compare
Issues:
Related docs:
Set stability level to preview for now. This may change later