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 < indu...@wso2.com> wrote: > Hi, > > > On Wed, Jan 10, 2018 at 12:24 PM, Indunil Upeksha Rathnayake < > indu...@wso2.com> wrote: > >> Hi, >> >> On Wed, Jan 3, 2018 at 6:05 PM, Asela Pathberiya <as...@wso2.com> wrote: >> >>> >>> >>> On Fri, Dec 15, 2017 at 10:11 AM, Darshana Gunawardana < >>> darsh...@wso2.com> wrote: >>> >>>> >>>> >>>> On Fri, Dec 15, 2017 at 9:02 AM, Indunil Upeksha Rathnayake < >>>> indu...@wso2.com> 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. > > >> >> >>> https://issues.apache.org/jira/browse/HTTPCLIENT-483 >>> https://stackoverflow.com/questions/20286145/validate-client >>> -certificate-against-certificate-revocation-list-in-tomcat-7 >>> >>> Did we check the pass-through transport implementation of our ESB >>> regarding this ? >>> >> > 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 indu...@wso2.com >>>>> Mobile 0772182255 >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> >>>> *Darshana Gunawardana*Technical Lead >>>> WSO2 Inc.; http://wso2.com >>>> >>>> *E-mail: darsh...@wso2.com <darsh...@wso2.com>* >>>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . >>>> Middleware >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Asela >>> >>> ATL >>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>> +358 449 228 979 >>> >>> http://soasecurity.org/ >>> http://xacmlinfo.org/ >>> >> >> >> >> -- >> Indunil Upeksha Rathnayake >> Software Engineer | WSO2 Inc >> Email indu...@wso2.com >> Mobile 0772182255 >> > > > > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Email indu...@wso2.com > Mobile 0772182255 > -- Indunil Upeksha Rathnayake Software Engineer | WSO2 Inc Email indu...@wso2.com Mobile 0772182255
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
