[openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Viktor Dukhovni]

> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> 
> If OpenSSL want to change the standard so that it aligns with the
> project's implementation then the project should go to LAMP.
> Otherwise, the project is acting without authority. OpenSSL cannot
> arbitrarily decide to do something else on a suggestion or a whim.

There is no "authority", nor is there an "Internet police".

> You know, this issue could have been side stepped by providing both
> behaviors, making one default, and allowing the user to make the
> choice. Instead, the project wrapped its arms around the solution that
> broke interop.

Actually, IIRC Mozilla's NSS and Microsoft's CAPI do the same thing.
So it is unclear where exactly we're breaking "interop".

> I can't help but wonder, doesn't anyone think these decisions through?

This was thought through and discussed.  I brought to the team's
attention:

   http://www-archive.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html

   The following table shows the OIDs recognized in the extended key usage
   extension, and how they map to cert types and key usages for CA and non-CA
   certs.

   extended key usage OID                  non-CA cert     CA cert
   -----------------------------------     --------------  ----------------
   SEC_OID_EXT_KEY_USAGE_EMAIL_PROTECT     EMAIL_CA        EMAIL_CA
   SEC_OID_EXT_KEY_USAGE_SERVER_AUTH       SSL_SERVER      SSL_CA
   SEC_OID_EXT_KEY_USAGE_CLIENT_AUTH       SSL_CLIENT      SSL_CA
   SEC_OID_EXT_KEY_USAGE_CODE_SIGN         OBJECT_SIGNING  OBJECT_SIGNING_CA
   SEC_OID_EXT_KEY_USAGE_TIME_STAMP        TIME_STAMP      TIME_STAMP
   SEC_OID_OCSP_RESPONDER                  OCSP_RESPONDER  OCSP_RESPONDER

   For CA certs in the cert chain, the requirements are:

   Cert Usage              Requried Key Usage      Required Cert Type
   --------------------    --------------------    -----------------------
   SSLServerWithStepUp:    GOVT_APPROVED AND 
			    CERT_SIGN;              SSL_CA;
   SSLClient:              CERT_SIGN;              SSL_CA;
   SSLServer:              CERT_SIGN;              SSL_CA;
   SSLCA:                  CERT_SIGN;              SSL_CA;
   EmailSigner:            CERT_SIGN;              EMAIL_CA or SSL_CA
   EmailRecipient:         CERT_SIGN;              EMAIL_CA or SSL_CA
   ObjectSigner:           CERT_SIGN;              OBJECT_SIGNING_CA;
   UsageAnyCA:             CERT_SIGN;              OBJECT_SIGNING_CA OR
						    EMAIL_CA OR
						    SSL_CA;

   When NSS is asked to verify the validity of a certificate chain, it
   verifies the validity of that cert chain for a particular purpose,
   known as a SECCertUsage, as of a specific date and time.  

   The list of known SECCertUsages is short:

   certUsageSSLClient ...........  An SSL client authentication cert
   certUsageSSLServer ...........  An ordinary SSL server cert
   certUsageSSLServerWithStepUp..  An SSL server cert that allows export 
				    clients to use strong crypto.
   certUsageSSLCA ...............  An intermediate or root CA cert allowed 
				    to issue SSL client or SSL server certs
				    or other intermediate SSL CA certs.
   certUsageEmailSigner .........  Used to verify S/MIME email signatures
   certUsageEmailRecipient ......  Used to encrypt S/MIME emails.
   certUsageObjectSigner ........  Used to verify signatures on files of 
				    executable code, e.g. jar files.
   certUsageStatusResponder .....  Used by an OCSP responder
   certUsageVerifyCA ............  A CA of any kind.

and:

   https://www.ietf.org/mail-archive/web/pkix/current/msg32409.html

   Frequently Asked Questions

   RFC 5280 reads "In general, this extension will appear only in
   end entity certificates".  Is it non-standard to have EKU in
   intermediate certificates, and will client software break when
   receiving such a certificate chain?

     o Inclusion of EKU in CA certificates is generally allowed.
       NSS and CryptoAPI both treat the EKU extension in intermediate
       certificates as a constraint on the permitted EKU OIDs in
       end-entity certificates. Browsers and certificate client
       software have been using EKU in intermediate certificates,
       and it has been common for enterprise subordinate CAs in
       Windows environments to use EKU in their intermediate
       certificates to constrain certificate issuance. Therefore,
       it is unlikely that using EKU in intermediate certificates
       would break other client software.

     o The use of the EKU extension in intermediate certificates
       was discussed at length in the mozilla.dev.security.policy
       forum.  We considered other options, such as standardizing
       a set of Policy OIDs or un-deprecating NetscapeCertType.
       The discussion included the concern that one interpretation
       of RFC 5280 is that this use of EKU is non-standard, but
       it was decided that the RFCs are not clear, and perhaps
       conflicting, in regards to EKUs in CA certificates.  In
       the discussion it was pointed out that other major browsers
       and client software already support this use of EKU but do
       not recognize NetscapeCertType; and we also recognized the
       difficulties involved in standardizing a set of Policy
       OIDs. The conclusion of the discussion was that EKU is the
       best tool for technically constraining the types of
       certificates that an intermediate certificate may sign.

I am sorry to hear that you're saddened by my lack of fealty to
RFC5280, but I find real-world considerations more compelling.
The OP in this thread has perfectly reasonable work-arounds,
the main obstacle seems to be a language barrier more than
anything else.

Over and out.

-- 
	Viktor.