[X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

Indunil Upeksha Rathnayake
Hi,

At the time, a certificate is issued by a Certificate Authority (CA), it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid, prior to the expiration of the validity period (Ex: compromise or suspected compromise of the corresponding private key). Under such circumstances, the issuing CA needs to revoke the certificate before their scheduled expiration date and should no longer be trusted.

CRL(Certificate Revocation List) and OCSP (Online Certificate Status Protocol) are two protocols used to check whether a given X509 Certificate is revoked by its Issuer.
  1. Certificate Revocation List (CRL) : a list of digital certificates that have been revoked by the issuing CA
  2. Online Certificate Status Protocol (OCSP) : an Internet protocol used for obtaining the revocation status of an X.509 digital certificate using the certificate serial number

Proposed implementation is to include certificate validation with CRL and OCSP, in X509 authenticator which is for client X.509 certificate authentication. So that at the verification phase of SSL handshake, OCSP/CRL certificate verification process, is used to contact the relevant Certificate Authority(CA) to verify the validity of the given certificate.  If the response says that the certificate is revoked, it means that the certificate is no longer trusted by the CA, in which case the SSL connection to the peer is terminated.



Please find the following architectural considerations for the proposed implementation.

APIs or Services for CRL/OCSP Validation :
Certificate Revocation Verification should be exposed as an OSGI service in a matter where we can include validation methods additionally via extensions.

Get CRL and OCSP URLs :
  • When a CA signs a certificate, it will normally encode the CRL and OCSP location/s into the certificate using "CRL Distribution Point" and "Authority Information Access" extensions respectively.
  • If CRL and OCSP location/s are not specified in the certificate or administrator wants to override that with a predefined locations in the server, we are planning to maintain a list of trusted CAs with CRL and OCSP location/s in registry.
Registry Structure : Two registry resources as follows and comma separated CRL/OCSP URls as property values mapping with the CA issuer name.
/_system/config/certificate/crl
/_system/config/certificate/ocsp

Trusted CA List : Consider the issuers in the default client-truststore of WSO2 products.

Caching Layer :
  • Downloaded CRL from CRL URL or OCSP response from OCSP URL will be cached.
  • CA provides a CRL that is valid for a limited amount of time and specifies the lifetime validity of the CRL in the "Next Update" CRL field. 
This field indicates the date by which the next CRL will be issued. As mentioned in [1], the next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.

So we should consider this property and validated the returned CRL from cache, since a certificate in the CRL can be temporary invalidated (Hold) rather a irreversibly revoked certificate and use of an outdated CRL creates security exposures.

Preference for CRL and OCSP :
  • Able to disable one or both methods and to define preference between CRL and OCSP - this will be through file based configuration
  • If both methods has enabled, verified with OCSP first, followed by CRL
  • By default (if not configured), verified with OCSP
Other Considerations :
  • Validate CRL returned from the CRL URL
    • CRL should signed by the issuer, so validate the issuer domain name.
    • Validate the signature of CRL with the issuer public certificate.
    • Validate the CRL "next update" date field for outdated CRLs.

Appreciate your suggestions/comments.

[1] https://tools.ietf.org/html/rfc5280
[2] https://tools.ietf.org/html/rfc6960

Thanks and Regards
--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

Prasanna Dangalla
Hi Indunil,

On Fri, Dec 15, 2017 at 9:02 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

At the time, a certificate is issued by a Certificate Authority (CA), it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid, prior to the expiration of the validity period (Ex: compromise or suspected compromise of the corresponding private key). Under such circumstances, the issuing CA needs to revoke the certificate before their scheduled expiration date and should no longer be trusted.

CRL(Certificate Revocation List) and OCSP (Online Certificate Status Protocol) are two protocols used to check whether a given X509 Certificate is revoked by its Issuer.
  1. Certificate Revocation List (CRL) : a list of digital certificates that have been revoked by the issuing CA
  2. Online Certificate Status Protocol (OCSP) : an Internet protocol used for obtaining the revocation status of an X.509 digital certificate using the certificate serial number

Proposed implementation is to include certificate validation with CRL and OCSP, in X509 authenticator which is for client X.509 certificate authentication. So that at the verification phase of SSL handshake, OCSP/CRL certificate verification process, is used to contact the relevant Certificate Authority(CA) to verify the validity of the given certificate.  If the response says that the certificate is revoked, it means that the certificate is no longer trusted by the CA, in which case the SSL connection to the peer is terminated.



Please find the following architectural considerations for the proposed implementation.

APIs or Services for CRL/OCSP Validation :
Certificate Revocation Verification should be exposed as an OSGI service in a matter where we can include validation methods additionally via extensions.

Get CRL and OCSP URLs :
  • When a CA signs a certificate, it will normally encode the CRL and OCSP location/s into the certificate using "CRL Distribution Point" and "Authority Information Access" extensions respectively.
  • If CRL and OCSP location/s are not specified in the certificate or administrator wants to override that with a predefined locations in the server, we are planning to maintain a list of trusted CAs with CRL and OCSP location/s in registry.
Registry Structure : Two registry resources as follows and comma separated CRL/OCSP URls as property values mapping with the CA issuer name.
/_system/config/certificate/crl
/_system/config/certificate/ocsp
In this scenario for a two node cluster setup do you have two separate certificates for two nodes? I believe its the same certificate. If its the same, you can have a config mount and inlcude the certificates in a cluster setup.

Trusted CA List : Consider the issuers in the default client-truststore of WSO2 products.

Caching Layer :
  • Downloaded CRL from CRL URL or OCSP response from OCSP URL will be cached.
  • CA provides a CRL that is valid for a limited amount of time and specifies the lifetime validity of the CRL in the "Next Update" CRL field. 
This field indicates the date by which the next CRL will be issued. As mentioned in [1], the next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.

So we should consider this property and validated the returned CRL from cache, since a certificate in the CRL can be temporary invalidated (Hold) rather a irreversibly revoked certificate and use of an outdated CRL creates security exposures.

Preference for CRL and OCSP :
  • Able to disable one or both methods and to define preference between CRL and OCSP - this will be through file based configuration
  • If both methods has enabled, verified with OCSP first, followed by CRL
  • By default (if not configured), verified with OCSP
Other Considerations :
  • Validate CRL returned from the CRL URL
    • CRL should signed by the issuer, so validate the issuer domain name.
    • Validate the signature of CRL with the issuer public certificate.
    • Validate the CRL "next update" date field for outdated CRLs.

Appreciate your suggestions/comments.

[1] https://tools.ietf.org/html/rfc5280
[2] https://tools.ietf.org/html/rfc6960

Thanks and Regards
--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

Johann Nallathamby
In reply to this post by Indunil Upeksha Rathnayake
Hi Indunil,

On Fri, Dec 15, 2017 at 9:02 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

At the time, a certificate is issued by a Certificate Authority (CA), it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid, prior to the expiration of the validity period (Ex: compromise or suspected compromise of the corresponding private key). Under such circumstances, the issuing CA needs to revoke the certificate before their scheduled expiration date and should no longer be trusted.

CRL(Certificate Revocation List) and OCSP (Online Certificate Status Protocol) are two protocols used to check whether a given X509 Certificate is revoked by its Issuer.
  1. Certificate Revocation List (CRL) : a list of digital certificates that have been revoked by the issuing CA
  2. Online Certificate Status Protocol (OCSP) : an Internet protocol used for obtaining the revocation status of an X.509 digital certificate using the certificate serial number

Proposed implementation is to include certificate validation with CRL and OCSP, in X509 authenticator which is for client X.509 certificate authentication. So that at the verification phase of SSL handshake, OCSP/CRL certificate verification process, is used to contact the relevant Certificate Authority(CA) to verify the validity of the given certificate.  If the response says that the certificate is revoked, it means that the certificate is no longer trusted by the CA, in which case the SSL connection to the peer is terminated.

The implementation should not just think of X509 authentication. The implementation should be a generic utility service that can be engaged in any component that use certificates. Good example is the TLS layer of our server. Once this component is done, ideally it should be like a simple effort to engage the same for certificate validation during TLS handshake as well. So the component has to be a independent component from X509 authenticator.
 




Please find the following architectural considerations for the proposed implementation.

APIs or Services for CRL/OCSP Validation :
Certificate Revocation Verification should be exposed as an OSGI service in a matter where we can include validation methods additionally via extensions.

Get CRL and OCSP URLs :
  • When a CA signs a certificate, it will normally encode the CRL and OCSP location/s into the certificate using "CRL Distribution Point" and "Authority Information Access" extensions respectively.
  • If CRL and OCSP location/s are not specified in the certificate or administrator wants to override that with a predefined locations in the server, we are planning to maintain a list of trusted CAs with CRL and OCSP location/s in registry.
Registry Structure : Two registry resources as follows and comma separated CRL/OCSP URls as property values mapping with the CA issuer name.
/_system/config/certificate/crl
/_system/config/certificate/ocsp

1. I think managing the list of CAs is a matter of organization governance more than product configuration, hence should go to governance space. Also if the component is to be used across multiple products it has to be in governance space so that we can mount across all the products.
2. "certificate" doesn't seem to be a good name. Shall we make it "certificate-authorities"?
3. Why are we restricting the extensibility and manageability of the structure so much by reducing it to just two resources? I suggest we have something like following.

Under "certificate-authorities" (in your structure "certificate") we can have a collection for each CA. Thereafter I am thinking we can have the certificates listed as resources under each CA collection. A CA can have multiple certificates if needed. For each certificate we can have two properties. One is the OCSP and other is the CRL. If there are multiple URLs, we can use some either comma separated form, or naming convention such as URL_1, URL_2, and so on. Better get advice for registry experts as to the pros and cons of these two forms when searching, indexing, etc.


Trusted CA List : Consider the issuers in the default client-truststore of WSO2 products.

Caching Layer :
  • Downloaded CRL from CRL URL or OCSP response from OCSP URL will be cached.
  • CA provides a CRL that is valid for a limited amount of time and specifies the lifetime validity of the CRL in the "Next Update" CRL field. 
This field indicates the date by which the next CRL will be issued. As mentioned in [1], the next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.

So we should consider this property and validated the returned CRL from cache, since a certificate in the CRL can be temporary invalidated (Hold) rather a irreversibly revoked certificate and use of an outdated CRL creates security exposures.

Preference for CRL and OCSP :
  • Able to disable one or both methods and to define preference between CRL and OCSP - this will be through file based configuration
Please make this also another property in the registry, since it has to be configured per tenant. Not need to splay configurations in registry and file system. 
  • If both methods has enabled, verified with OCSP first, followed by CRL
Did you come to this conclusion by reading up on any recommendations? 
  • By default (if not configured), verified with OCSP
Did you come to this conclusion by reading up on any recommendations?  

Regards,
Johann.
Other Considerations :
  • Validate CRL returned from the CRL URL
    • CRL should signed by the issuer, so validate the issuer domain name.
    • Validate the signature of CRL with the issuer public certificate.
    • Validate the CRL "next update" date field for outdated CRLs.

Appreciate your suggestions/comments.

[1] https://tools.ietf.org/html/rfc5280
[2] https://tools.ietf.org/html/rfc6960

Thanks and Regards
--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

Darshana Gunawardana
In reply to this post by Indunil Upeksha Rathnayake


On Fri, Dec 15, 2017 at 9:02 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

At the time, a certificate is issued by a Certificate Authority (CA), it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid, prior to the expiration of the validity period (Ex: compromise or suspected compromise of the corresponding private key). Under such circumstances, the issuing CA needs to revoke the certificate before their scheduled expiration date and should no longer be trusted.

CRL(Certificate Revocation List) and OCSP (Online Certificate Status Protocol) are two protocols used to check whether a given X509 Certificate is revoked by its Issuer.
  1. Certificate Revocation List (CRL) : a list of digital certificates that have been revoked by the issuing CA
  2. Online Certificate Status Protocol (OCSP) : an Internet protocol used for obtaining the revocation status of an X.509 digital certificate using the certificate serial number

Proposed implementation is to include certificate validation with CRL and OCSP, in X509 authenticator which is for client X.509 certificate authentication. So that at the verification phase of SSL handshake, OCSP/CRL certificate verification process, is used to contact the relevant Certificate Authority(CA) to verify the validity of the given certificate.  If the response says that the certificate is revoked, it means that the certificate is no longer trusted by the CA, in which case the SSL connection to the peer is terminated.



Please find the following architectural considerations for the proposed implementation.

APIs or Services for CRL/OCSP Validation :
Certificate Revocation Verification should be exposed as an OSGI service in a matter where we can include validation methods additionally via extensions.

+1 There are two angels here,
  1. This service should not be coupled with the X509 Authenticator, any other component that have the same requirement should be able to consume this service without an issue.
  2. Ability to plug different implementations for validations.

Get CRL and OCSP URLs :
  • When a CA signs a certificate, it will normally encode the CRL and OCSP location/s into the certificate using "CRL Distribution Point" and "Authority Information Access" extensions respectively.
  • If CRL and OCSP location/s are not specified in the certificate or administrator wants to override that with a predefined locations in the server, we are planning to maintain a list of trusted CAs with CRL and OCSP location/s in registry.
Registry Structure : Two registry resources as follows and comma separated CRL/OCSP URls as property values mapping with the CA issuer name.
/_system/config/certificate/crl
/_system/config/certificate/ocsp

Trusted CA List : Consider the issuers in the default client-truststore of WSO2 products.

Caching Layer :
  • Downloaded CRL from CRL URL or OCSP response from OCSP URL will be cached.
  • CA provides a CRL that is valid for a limited amount of time and specifies the lifetime validity of the CRL in the "Next Update" CRL field. 
This field indicates the date by which the next CRL will be issued. As mentioned in [1], the next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.  

So we should consider this property and validated the returned CRL from cache, since a certificate in the CRL can be temporary invalidated (Hold) rather a irreversibly revoked certificate and use of an outdated CRL creates security exposures.

AFAIU, we could have ended up having invalid entries in cache, if we rely on 'Next Update' field. So how exactly are we going to cache CRL and OSCP?

Preference for CRL and OCSP :
  • Able to disable one or both methods and to define preference between CRL and OCSP - this will be through file based configuration
  • If both methods has enabled, verified with OCSP first, followed by CRL
  • By default (if not configured), verified with OCSP

At least we should have extensible mechanism to override these to certificate level. ie. configuration levels would be, server -> tenant -> sp -> certificate. 

Thanks,
Other Considerations :
  • Validate CRL returned from the CRL URL
    • CRL should signed by the issuer, so validate the issuer domain name.
    • Validate the signature of CRL with the issuer public certificate.
    • Validate the CRL "next update" date field for outdated CRLs.

Appreciate your suggestions/comments.

[1] https://tools.ietf.org/html/rfc5280
[2] https://tools.ietf.org/html/rfc6960

Thanks and Regards
--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Regards,

Darshana Gunawardana
Technical Lead
WSO2 Inc.; http://wso2.com
E-mail: [hidden email]
Mobile: +94718566859
Lean . Enterprise . Middleware


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

Johann Nallathamby
In reply to this post by Indunil Upeksha Rathnayake
Hi Indunil,

On Fri, Dec 15, 2017 at 7:32 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

At the time, a certificate is issued by a Certificate Authority (CA), it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid, prior to the expiration of the validity period (Ex: compromise or suspected compromise of the corresponding private key). Under such circumstances, the issuing CA needs to revoke the certificate before their scheduled expiration date and should no longer be trusted.

CRL(Certificate Revocation List) and OCSP (Online Certificate Status Protocol) are two protocols used to check whether a given X509 Certificate is revoked by its Issuer.
  1. Certificate Revocation List (CRL) : a list of digital certificates that have been revoked by the issuing CA
  2. Online Certificate Status Protocol (OCSP) : an Internet protocol used for obtaining the revocation status of an X.509 digital certificate using the certificate serial number

Proposed implementation is to include certificate validation with CRL and OCSP, in X509 authenticator which is for client X.509 certificate authentication. So that at the verification phase of SSL handshake, OCSP/CRL certificate verification process, is used to contact the relevant Certificate Authority(CA) to verify the validity of the given certificate.  If the response says that the certificate is revoked, it means that the certificate is no longer trusted by the CA, in which case the SSL connection to the peer is terminated.



Please find the following architectural considerations for the proposed implementation.

APIs or Services for CRL/OCSP Validation :
Certificate Revocation Verification should be exposed as an OSGI service in a matter where we can include validation methods additionally via extensions.

Get CRL and OCSP URLs :
  • When a CA signs a certificate, it will normally encode the CRL and OCSP location/s into the certificate using "CRL Distribution Point" and "Authority Information Access" extensions respectively.
  • If CRL and OCSP location/s are not specified in the certificate or administrator wants to override that with a predefined locations in the server, we are planning to maintain a list of trusted CAs with CRL and OCSP location/s in registry.
Registry Structure : Two registry resources as follows and comma separated CRL/OCSP URls as property values mapping with the CA issuer name.
/_system/config/certificate/crl
/_system/config/certificate/ocsp

Trusted CA List : Consider the issuers in the default client-truststore of WSO2 products.

Here I think we need to have a separate trust store for x509 user authentication. The client-truststore.jks is mainly used TLS trust. Using the same for X509 also will be pointless, because the whole purpose of having this trust store is to limit certificates we trust. If we have only one trust store for both TLS, and X509 user authentication we can't have separate set of CAs for these.

Regards,
Johann.


Caching Layer :
  • Downloaded CRL from CRL URL or OCSP response from OCSP URL will be cached.
  • CA provides a CRL that is valid for a limited amount of time and specifies the lifetime validity of the CRL in the "Next Update" CRL field. 
This field indicates the date by which the next CRL will be issued. As mentioned in [1], the next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.

So we should consider this property and validated the returned CRL from cache, since a certificate in the CRL can be temporary invalidated (Hold) rather a irreversibly revoked certificate and use of an outdated CRL creates security exposures.

Preference for CRL and OCSP :
  • Able to disable one or both methods and to define preference between CRL and OCSP - this will be through file based configuration
  • If both methods has enabled, verified with OCSP first, followed by CRL
  • By default (if not configured), verified with OCSP
Other Considerations :
  • Validate CRL returned from the CRL URL
    • CRL should signed by the issuer, so validate the issuer domain name.
    • Validate the signature of CRL with the issuer public certificate.
    • Validate the CRL "next update" date field for outdated CRLs.

Appreciate your suggestions/comments.

[1] https://tools.ietf.org/html/rfc5280
[2] https://tools.ietf.org/html/rfc6960

Thanks and Regards
--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

Indunil Upeksha Rathnayake
Hi,

Thanks a lot for your valuable feedbacks. Please find the current implementation details as follows. 
  • Certificate validators can be configured in <IS_HOME>/repository/conf/security/certificate-validators.xml as follows with configured priorities. This will be added to tenant registry in /_system/governance/repository/security/certificate/validator on tenant activation. There will be separate resources for each validator with properties as name, enable and priority.
<Validators xmlns="http://wso2.org/projects/carbon/certificate-validators.xml">
    <Validator name="org.wso2.carbon.identity.x509Certificate.validation.crl.CRLValidator" displayName="CRLValidator" enable="true">
        <Priority>1</Priority>
    </Validator>
    <Validator name="org.wso2.carbon.identity.x509Certificate.validation.ocsp.OCSPValidator" displayName="OCSPValidator" enable="false">
        <Priority>2</Priority>
    </Validator>
</Validators>

  • An OSGI service which will be exposed to verify the certification revocation. In there, all the validator configs will be loaded from the registry and based on the enability and priority, corresponding validators will get invoked.
  • CRL Validator has been implemented as follows.
    • Extract the certificate extension value for CRL Distribution points.
    • Retrieve CRL URLs from the CRL Distribution points.
    • Download X509CRL from the CRL URLs (If one fails check with the other) or retrieve from the cache and check the revocation status.
  • Client certificate will be validated in X509CertificateAuthenticator when processing authentication response. If the given X509 Certificate is revoked by its Issuer, will be throwing an exception. In there, when a certificate has been revoked, if already a user certificate exists which matches with the cert in request, will be deleting the certificate from user claims.


Thanks and Regards


On Tue, Dec 19, 2017 at 7:32 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Indunil,

On Fri, Dec 15, 2017 at 7:32 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

At the time, a certificate is issued by a Certificate Authority (CA), it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid, prior to the expiration of the validity period (Ex: compromise or suspected compromise of the corresponding private key). Under such circumstances, the issuing CA needs to revoke the certificate before their scheduled expiration date and should no longer be trusted.

CRL(Certificate Revocation List) and OCSP (Online Certificate Status Protocol) are two protocols used to check whether a given X509 Certificate is revoked by its Issuer.
  1. Certificate Revocation List (CRL) : a list of digital certificates that have been revoked by the issuing CA
  2. Online Certificate Status Protocol (OCSP) : an Internet protocol used for obtaining the revocation status of an X.509 digital certificate using the certificate serial number

Proposed implementation is to include certificate validation with CRL and OCSP, in X509 authenticator which is for client X.509 certificate authentication. So that at the verification phase of SSL handshake, OCSP/CRL certificate verification process, is used to contact the relevant Certificate Authority(CA) to verify the validity of the given certificate.  If the response says that the certificate is revoked, it means that the certificate is no longer trusted by the CA, in which case the SSL connection to the peer is terminated.



Please find the following architectural considerations for the proposed implementation.

APIs or Services for CRL/OCSP Validation :
Certificate Revocation Verification should be exposed as an OSGI service in a matter where we can include validation methods additionally via extensions.

Get CRL and OCSP URLs :
  • When a CA signs a certificate, it will normally encode the CRL and OCSP location/s into the certificate using "CRL Distribution Point" and "Authority Information Access" extensions respectively.
  • If CRL and OCSP location/s are not specified in the certificate or administrator wants to override that with a predefined locations in the server, we are planning to maintain a list of trusted CAs with CRL and OCSP location/s in registry.
Registry Structure : Two registry resources as follows and comma separated CRL/OCSP URls as property values mapping with the CA issuer name.
/_system/config/certificate/crl
/_system/config/certificate/ocsp

Trusted CA List : Consider the issuers in the default client-truststore of WSO2 products.

Here I think we need to have a separate trust store for x509 user authentication. The client-truststore.jks is mainly used TLS trust. Using the same for X509 also will be pointless, because the whole purpose of having this trust store is to limit certificates we trust. If we have only one trust store for both TLS, and X509 user authentication we can't have separate set of CAs for these.

Regards,
Johann.


Caching Layer :
  • Downloaded CRL from CRL URL or OCSP response from OCSP URL will be cached.
  • CA provides a CRL that is valid for a limited amount of time and specifies the lifetime validity of the CRL in the "Next Update" CRL field. 
This field indicates the date by which the next CRL will be issued. As mentioned in [1], the next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.

So we should consider this property and validated the returned CRL from cache, since a certificate in the CRL can be temporary invalidated (Hold) rather a irreversibly revoked certificate and use of an outdated CRL creates security exposures.

Preference for CRL and OCSP :
  • Able to disable one or both methods and to define preference between CRL and OCSP - this will be through file based configuration
  • If both methods has enabled, verified with OCSP first, followed by CRL
  • By default (if not configured), verified with OCSP
Other Considerations :
  • Validate CRL returned from the CRL URL
    • CRL should signed by the issuer, so validate the issuer domain name.
    • Validate the signature of CRL with the issuer public certificate.
    • Validate the CRL "next update" date field for outdated CRLs.

Appreciate your suggestions/comments.

[1] https://tools.ietf.org/html/rfc5280
[2] https://tools.ietf.org/html/rfc6960

Thanks and Regards
--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

Indunil Upeksha Rathnayake
In reply to this post by Darshana Gunawardana
Hi,

On Wed, Jan 10, 2018 at 12:24 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

On Wed, Jan 3, 2018 at 6:05 PM, Asela Pathberiya <[hidden email]> wrote:


On Fri, Dec 15, 2017 at 10:11 AM, Darshana Gunawardana <[hidden email]> wrote:


On Fri, Dec 15, 2017 at 9:02 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

At the time, a certificate is issued by a Certificate Authority (CA), it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid, prior to the expiration of the validity period (Ex: compromise or suspected compromise of the corresponding private key). Under such circumstances, the issuing CA needs to revoke the certificate before their scheduled expiration date and should no longer be trusted.

CRL(Certificate Revocation List) and OCSP (Online Certificate Status Protocol) are two protocols used to check whether a given X509 Certificate is revoked by its Issuer.
  1. Certificate Revocation List (CRL) : a list of digital certificates that have been revoked by the issuing CA
  2. Online Certificate Status Protocol (OCSP) : an Internet protocol used for obtaining the revocation status of an X.509 digital certificate using the certificate serial number

Proposed implementation is to include certificate validation with CRL and OCSP, in X509 authenticator which is for client X.509 certificate authentication. So that at the verification phase of SSL handshake, OCSP/CRL certificate verification process, is used to contact the relevant Certificate Authority(CA) to verify the validity of the given certificate.  If the response says that the certificate is revoked, it means that the certificate is no longer trusted by the CA, in which case the SSL connection to the peer is terminated.



Please find the following architectural considerations for the proposed implementation.

APIs or Services for CRL/OCSP Validation :
Certificate Revocation Verification should be exposed as an OSGI service in a matter where we can include validation methods additionally via extensions.

+1 There are two angels here,
  1. This service should not be coupled with the X509 Authenticator, any other component that have the same requirement should be able to consume this service without an issue.
  2. Ability to plug different implementations for validations.

Can't this be an extension to the tomcat transport & http client implementation?  Then it may cover all the TLS transports

You are referring enabling OCSP/CRL validation in tomcat connector level? If so, I think we need to do the validation through a valve, but need to check whether a valve can be enabled tomcat connector wise. WDYT?
Since, we are exposing the OCSP/CRL validation in an OSGI service, it can be engaged from any component.
 

Yes checked the pass-through transport implementation for this.
 
 

Thanks,
Asela.
 

Get CRL and OCSP URLs :
  • When a CA signs a certificate, it will normally encode the CRL and OCSP location/s into the certificate using "CRL Distribution Point" and "Authority Information Access" extensions respectively.
  • If CRL and OCSP location/s are not specified in the certificate or administrator wants to override that with a predefined locations in the server, we are planning to maintain a list of trusted CAs with CRL and OCSP location/s in registry.
Registry Structure : Two registry resources as follows and comma separated CRL/OCSP URls as property values mapping with the CA issuer name.
/_system/config/certificate/crl
/_system/config/certificate/ocsp

Trusted CA List : Consider the issuers in the default client-truststore of WSO2 products.

Caching Layer :
  • Downloaded CRL from CRL URL or OCSP response from OCSP URL will be cached.
  • CA provides a CRL that is valid for a limited amount of time and specifies the lifetime validity of the CRL in the "Next Update" CRL field. 
This field indicates the date by which the next CRL will be issued. As mentioned in [1], the next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.  

So we should consider this property and validated the returned CRL from cache, since a certificate in the CRL can be temporary invalidated (Hold) rather a irreversibly revoked certificate and use of an outdated CRL creates security exposures.

AFAIU, we could have ended up having invalid entries in cache, if we rely on 'Next Update' field. So how exactly are we going to cache CRL and OSCP?

Preference for CRL and OCSP :
  • Able to disable one or both methods and to define preference between CRL and OCSP - this will be through file based configuration
  • If both methods has enabled, verified with OCSP first, followed by CRL
  • By default (if not configured), verified with OCSP

At least we should have extensible mechanism to override these to certificate level. ie. configuration levels would be, server -> tenant -> sp -> certificate. 

Thanks,
Other Considerations :
  • Validate CRL returned from the CRL URL
    • CRL should signed by the issuer, so validate the issuer domain name.
    • Validate the signature of CRL with the issuer public certificate.
    • Validate the CRL "next update" date field for outdated CRLs.

Appreciate your suggestions/comments.

[1] https://tools.ietf.org/html/rfc5280
[2] https://tools.ietf.org/html/rfc6960

Thanks and Regards
--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Regards,

Darshana Gunawardana
Technical Lead
WSO2 Inc.; http://wso2.com
E-mail: [hidden email]
Mobile: <a href="tel:+94%2071%20856%206859" value="+94718566859" target="_blank">+94718566859
Lean . Enterprise . Middleware




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +358 449 228 979

http://soasecurity.org/
http://xacmlinfo.org/



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

Indunil Upeksha Rathnayake
Hi,

Please find the following considerations on proceeding with the CRL/OCSP certificate validation. Appreciate your ideas and comments on this.

Store root CA and intermediate CA certificates in registry
  • As per the current implementation, trust stores which are having CA certificates that should be used for CRL and OCSP validation, can be configured file based as follows.

    <?xml version="1.0" encoding="ISO-8859-1"?>

    <CertificateValidation xmlns="http://wso2.org/projects/carbon/certificate-validation.xml">

    …….

    <TrustStores>

       <TrustStore truststoreFile="/path/to/truststore.jks" truststorePass="cacertspassword" type="JKS"/>

    </TrustStores>

    </CertificateValidation>

  • In server start up and in tenant initial activation, all the certificates in the trust stores will added to the registry.
Registry path : repository/security/certificate/certificate-authorities/<Normalized Issuer DN>/<Certificate Serial Num>

Normalized Issuer DN : UTF-8 URL encoded issuer DN while replacing the "%" with ":" in the URL encoded value, in order to support the Illegal characters for registry resource path (Check mail in [1]).
Certificate Serial Num : Positive integer assigned by the CA to each certificate which is unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate)

Registry Content : X509Certificate CA Certificate
Registry Properties :
crl - comma separated CRL URLs
ocsp - comma separated OCSP URLs
  • There can be certificates of Intermediate CAs and root CAs in the trust store (An intermediate CA is an entity that can sign certificates on behalf of the root CA. The root CA signs the intermediate certificate, forming a chain of trust). All those intermediate  and root certificates will be added into the registry considering following scenarios.
    1. Intermediate CAs have their own CRL and OCSP URLs
Revocation of certificate is not propagated across the CA tree. Each CA (root and intermediate) is responsible of the publication of the CRL containing the list of only the revoked certificates that were issued by that CA and OCSP response for only the certificates that were issued by that CA.

                   2. Observer intermediate CA certificates in the chain of trust
For full-chain CRL/OCSP validation as mention in below, need to have access to intermediate CA certificates in the chain of trust to retrieve the CRL and OCSP Urls


Need of CA and intermediate CA Certificates for CRL/OCSP validation
  • CRL Validation :
    • If the CA certificate available in the registry which issued the client certificate, retrieve the CRL URLs from the CA cert. If not use the URLs in the client certificate.
    • In order to validate intermediate CAs when Full-chain CRL/OCSP validation enabled, CRL URls will be extracted from corresponding root CA.
  • OCSP Validation :
    • For OCSP validation, CA certificate which issued the client certificate should be available in the registry. Otherwise consider as a unsuccessful validation.
    • In order to validate intermediate CAs when Full-chain CRL/OCSP validation enabled, OCSP URLs will be extracted from corresponding root CA.


Configure Full-chain CRL/OCSP Validation

<?xml version="1.0" encoding="ISO-8859-1"?>

<CertificateValidation xmlns="http://wso2.org/projects/carbon/certificate-validation.xml">

<Validators>

    <Validator name="org.wso2.carbon.identity.x509Certificate.validation.validator.CRLValidator" displayName="CRLValidator" enable="false">

              <Parameter name="priority">1</Parameter>

               <Parameter name="fullChainValidation">true</Parameter>                  

    </Validator>

    <Validator name="org.wso2.carbon.identity.x509Certificate.validation.validator.OCSPValidator" displayName="OCSPValidator" enable="true">

              <Parameter name="priority">2</Parameter>

               <Parameter name="fullChainValidation">true</Parameter>

    </Validator>

</Validators>

</CertificateValidation>

  • Full-chain CRL/OCSP validation disabled: validate the client certificate with the CRL/OCSP URLs of the issuer CA
  • Full-chain CRL/OCSP validation enabled: validate with the CRL/OCSP of every intermediate certificate within the chain of trust for the client, except for the root CA certificate.
Ex:  Root CA (root CA CRL) Cert ==> Intermediate CA Cert(inter CA CRL) ==> Client Cert
The intermediate CA CRL is used to verify whether the client certificate is valid. The root CA CRL is used to verify whether Intermediate CA Cert is valid.

If Full-chain CRL/OCSP checking enabled, If the intermediate certificates are not available in the registry or, if a CRL is not available in any of the intermediate CA in the chain of trust, or the certificate is listed as revoked in any of those CRLs, the client request is denied.


Validate when both CRL and OCSP methods are enabled
If the highest priority method returns a successful validation or status is not "Unknown", the second method is not attempted. Method with second and further priority is used as a backup.


Validate when multiple CA certificates
If there are CA certs more than one with same subject DN matches to issuer DN in client certificate, will be validating through one certificate. If validation is not successful or status is "Unknown", check with the CRL/OCSP URLs in the other CA certificate.


Validate when multiple CRL/OCSP URLs in a CA certificate/client certificate
Check with one URL and if only the validation is not successful or status is "Unknown", check with the other CRL/OCSP URLs in the certificate.


Number of Retries
Configure the maximum number of times which we can attempt to download the CRL file or get OCSP response from the specified path before giving up.

<?xml version="1.0" encoding="ISO-8859-1"?>

<CertificateValidation xmlns="http://wso2.org/projects/carbon/certificate-validation.xml">

<Validators>

    <Validator name="org.wso2.carbon.identity.x509Certificate.validation.validator.CRLValidator" displayName="CRLValidator" enable="true">
<Parameter name="priority">1</Parameter>

                <Parameter name="retryCount">2</Parameter>                                    

    </Validator>

</Validators>

</CertificateValidation>




[1] Mail Thread : "[Dev] Illegal Characters for Registry Resource Path"

Thanks and Regards


On Wed, Jan 10, 2018 at 12:41 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,


On Wed, Jan 10, 2018 at 12:24 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

On Wed, Jan 3, 2018 at 6:05 PM, Asela Pathberiya <[hidden email]> wrote:


On Fri, Dec 15, 2017 at 10:11 AM, Darshana Gunawardana <[hidden email]> wrote:


On Fri, Dec 15, 2017 at 9:02 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

At the time, a certificate is issued by a Certificate Authority (CA), it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid, prior to the expiration of the validity period (Ex: compromise or suspected compromise of the corresponding private key). Under such circumstances, the issuing CA needs to revoke the certificate before their scheduled expiration date and should no longer be trusted.

CRL(Certificate Revocation List) and OCSP (Online Certificate Status Protocol) are two protocols used to check whether a given X509 Certificate is revoked by its Issuer.
  1. Certificate Revocation List (CRL) : a list of digital certificates that have been revoked by the issuing CA
  2. Online Certificate Status Protocol (OCSP) : an Internet protocol used for obtaining the revocation status of an X.509 digital certificate using the certificate serial number

Proposed implementation is to include certificate validation with CRL and OCSP, in X509 authenticator which is for client X.509 certificate authentication. So that at the verification phase of SSL handshake, OCSP/CRL certificate verification process, is used to contact the relevant Certificate Authority(CA) to verify the validity of the given certificate.  If the response says that the certificate is revoked, it means that the certificate is no longer trusted by the CA, in which case the SSL connection to the peer is terminated.



Please find the following architectural considerations for the proposed implementation.

APIs or Services for CRL/OCSP Validation :
Certificate Revocation Verification should be exposed as an OSGI service in a matter where we can include validation methods additionally via extensions.

+1 There are two angels here,
  1. This service should not be coupled with the X509 Authenticator, any other component that have the same requirement should be able to consume this service without an issue.
  2. Ability to plug different implementations for validations.

Can't this be an extension to the tomcat transport & http client implementation?  Then it may cover all the TLS transports

You are referring enabling OCSP/CRL validation in tomcat connector level? If so, I think we need to do the validation through a valve, but need to check whether a valve can be enabled tomcat connector wise. WDYT?
Since, we are exposing the OCSP/CRL validation in an OSGI service, it can be engaged from any component.
 

Yes checked the pass-through transport implementation for this.
 
 

Thanks,
Asela.
 

Get CRL and OCSP URLs :
  • When a CA signs a certificate, it will normally encode the CRL and OCSP location/s into the certificate using "CRL Distribution Point" and "Authority Information Access" extensions respectively.
  • If CRL and OCSP location/s are not specified in the certificate or administrator wants to override that with a predefined locations in the server, we are planning to maintain a list of trusted CAs with CRL and OCSP location/s in registry.
Registry Structure : Two registry resources as follows and comma separated CRL/OCSP URls as property values mapping with the CA issuer name.
/_system/config/certificate/crl
/_system/config/certificate/ocsp

Trusted CA List : Consider the issuers in the default client-truststore of WSO2 products.

Caching Layer :
  • Downloaded CRL from CRL URL or OCSP response from OCSP URL will be cached.
  • CA provides a CRL that is valid for a limited amount of time and specifies the lifetime validity of the CRL in the "Next Update" CRL field. 
This field indicates the date by which the next CRL will be issued. As mentioned in [1], the next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.  

So we should consider this property and validated the returned CRL from cache, since a certificate in the CRL can be temporary invalidated (Hold) rather a irreversibly revoked certificate and use of an outdated CRL creates security exposures.

AFAIU, we could have ended up having invalid entries in cache, if we rely on 'Next Update' field. So how exactly are we going to cache CRL and OSCP?

Preference for CRL and OCSP :
  • Able to disable one or both methods and to define preference between CRL and OCSP - this will be through file based configuration
  • If both methods has enabled, verified with OCSP first, followed by CRL
  • By default (if not configured), verified with OCSP

At least we should have extensible mechanism to override these to certificate level. ie. configuration levels would be, server -> tenant -> sp -> certificate. 

Thanks,
Other Considerations :
  • Validate CRL returned from the CRL URL
    • CRL should signed by the issuer, so validate the issuer domain name.
    • Validate the signature of CRL with the issuer public certificate.
    • Validate the CRL "next update" date field for outdated CRLs.

Appreciate your suggestions/comments.

[1] https://tools.ietf.org/html/rfc5280
[2] https://tools.ietf.org/html/rfc6960

Thanks and Regards
--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Regards,

Darshana Gunawardana
Technical Lead
WSO2 Inc.; http://wso2.com
E-mail: [hidden email]
Mobile: <a href="tel:+94%2071%20856%206859" value="+94718566859" target="_blank">+94718566859
Lean . Enterprise . Middleware




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +358 449 228 979

http://soasecurity.org/
http://xacmlinfo.org/



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture