Hi Indunil, On Fri, Dec 15, 2017 at 9:02 AM, Indunil Upeksha Rathnayake < [email protected]> 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 [email protected] > Mobile 0772182255 >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
