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

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

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

Jeffrey Walton-3
On Mon, Jan 22, 2018 at 1:44 AM, Gladewitz, Robert via openssl-users
<[hidden email]> wrote:
>
> Thank you all for all the answers.
> The problem is that Cisco prescribes the attributes.
> ...
>
> Unfortunately, the Cisco CUCM telephone systems do not seem to accept certificates without these attributes :-(.
>
> If I understand everything correctly, would the only (and unclean) workaround be adding "TLS Web Client Authentication" to solve my problem?
>

I think you have a couple of choices.

First, you can downgrade to a version of OpenSSL that follows the RFC.
Second, you can patch OpenSSL to follow the RFC. Third, you can
implement the verify_callback and override the errant behavior.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
Hello Jeff,

That will be difficult. By complience policy, our servers are on Debian / Cent of the current stable version. Even patches code should not be used :-)

Does you already know when a version of OpenSSL will be released that follows this RFC?

Robert


-----Ursprüngliche Nachricht-----
Von: Jeffrey Walton [mailto:[hidden email]]
Gesendet: Montag, 22. Januar 2018 07:47
An: Gladewitz, Robert <[hidden email]>; OpenSSL Users <[hidden email]>
Betreff: Re: [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

On Mon, Jan 22, 2018 at 1:44 AM, Gladewitz, Robert via openssl-users <[hidden email]> wrote:
>
> Thank you all for all the answers.
> The problem is that Cisco prescribes the attributes.
> ...
>
> Unfortunately, the Cisco CUCM telephone systems do not seem to accept certificates without these attributes :-(.
>
> If I understand everything correctly, would the only (and unclean) workaround be adding "TLS Web Client Authentication" to solve my problem?
>

I think you have a couple of choices.

First, you can downgrade to a version of OpenSSL that follows the RFC.
Second, you can patch OpenSSL to follow the RFC. Third, you can implement the verify_callback and override the errant behavior.

Jeff

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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
In reply to this post by Jeffrey Walton-3


> On Jan 22, 2018, at 1:47 AM, Jeffrey Walton <[hidden email]> wrote:
>
> I think you have a couple of choices.
>
> First, you can downgrade to a version of OpenSSL that follows the RFC.
> Second, you can patch OpenSSL to follow the RFC. Third, you can
> implement the verify_callback and override the errant behavior.

None of this is necessary.  The OP indicates that the *leaf* certificate
has certain required extended key usages, but there is no indication that
the same applies to the intermediate CA.

The solution is to use a CA chain in which NONE of the CA certificates
have an extended key usage extension.  ONLY the leaf certificate should
have that extension.

CA certificates should have extended key usage specified when intended
to only issue leaf certificates that are to be used ONLY for the listed
purposes.  General-purpose CAs should not have extended key usage.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
In reply to this post by OpenSSL - User mailing list


> On Jan 22, 2018, at 1:57 AM, Gladewitz, Robert via openssl-users <[hidden email]> wrote:
>
> Does you already know when a version of OpenSSL will be released that follows this RFC?

The RFC is out of touch with real-world practice by multiple
implementations.  There are no plans to "follow the RFC".

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
Hello Viktor,

the problem is, that i cant change the cisco implementation :-(. Cisco tell
me, the capf implemtation is following all rfc documents. If you are right,
i cant use any freeradius implementation, because there are based on
openssl. There is no option in freeradius, to ignore some think like this.

For my understanding, CA certificate may have these exteded keys - it's just
something out of the ordinary. So, you mean, there is no chance to get this
correct rfc interpretation to openssl??

Cisco:
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-co
mmunications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed
-by.pdf
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-co
mmunications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed
-by.html

Regards

Robert





-----Ursprüngliche Nachricht-----
Von: openssl-users [mailto:[hidden email]] Im Auftrag von
Viktor Dukhovni
Gesendet: Montag, 22. Januar 2018 17:01
An: [hidden email]
Betreff: Re: [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



> On Jan 22, 2018, at 1:57 AM, Gladewitz, Robert via openssl-users
<[hidden email]> wrote:
>
> Does you already know when a version of OpenSSL will be released that
follows this RFC?

The RFC is out of touch with real-world practice by multiple
implementations.  There are no plans to "follow the RFC".

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
Perhaps ask what other FreeRadius users do, on one of their support forums?  I doubt you are the first to run into this.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
In reply to this post by OpenSSL - User mailing list


> On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users <[hidden email]> wrote:
>
> the problem is, that i cant change the cisco implementation :-(.

YOU DO NOT need to change the Cisco implementation.

> Cisco tell me, the capf implemtation is following all rfc documents.

Nothing Cisco is telling you requires your issuing CA to have an
extended key usage listing just "TLS Web Server Authentication".

> If you are right,
> i cant use any freeradius implementation, because there are based on
> openssl. There is no option in freeradius, to ignore some think like this.

Your problem is a misconfigured CA certificate.  Make sure your *CA*
certificate has no extended key usage specified, OR has *all* the key
usages specified that are required by any leaf certificate it will issue.

> For my understanding, CA certificate may have these exteded keys - it's just
> something out of the ordinary.

The extended key usages on the CA are interpreted to LIMIT the key usages
of certificates it can issue.  You can certainly use this extension, but
then expect the CA to be invalid for key usages you did not list.

> So, you mean, there is no chance to get this correct rfc interpretation
> to openssl?

"Correct" is in the eye of the beholder.  The RFC5280 alternative to
using the extended key usage (X.509 policy) is a complex mess.  Many
implementations do the sensible thing and overload the extended key
usage instead.  OpenSSL is among these and this is unlikely to change.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
Hello Viktor,

Sorry, I did not mean to upset you.

Somehow I seem to have misunderstood something.

The CAPF certificate is the CA certificate he goes for?
Cisco states that this certificate requires both CA and the extended key "TLS Web Server Authentification"?

Viktor, can you please write me directly??

Robert

-----Ursprüngliche Nachricht-----
Von: openssl-users [mailto:[hidden email]] Im Auftrag von Viktor Dukhovni
Gesendet: Montag, 22. Januar 2018 20:50
An: [hidden email]
Betreff: Re: [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



> On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users <[hidden email]> wrote:
>
> the problem is, that i cant change the cisco implementation :-(.

YOU DO NOT need to change the Cisco implementation.

> Cisco tell me, the capf implemtation is following all rfc documents.

Nothing Cisco is telling you requires your issuing CA to have an extended key usage listing just "TLS Web Server Authentication".

> If you are right,
> i cant use any freeradius implementation, because there are based on
> openssl. There is no option in freeradius, to ignore some think like this.

Your problem is a misconfigured CA certificate.  Make sure your *CA* certificate has no extended key usage specified, OR has *all* the key usages specified that are required by any leaf certificate it will issue.

> For my understanding, CA certificate may have these exteded keys -
> it's just something out of the ordinary.

The extended key usages on the CA are interpreted to LIMIT the key usages of certificates it can issue.  You can certainly use this extension, but then expect the CA to be invalid for key usages you did not list.

> So, you mean, there is no chance to get this correct rfc
> interpretation to openssl?

"Correct" is in the eye of the beholder.  The RFC5280 alternative to using the extended key usage (X.509 policy) is a complex mess.  Many implementations do the sensible thing and overload the extended key usage instead.  OpenSSL is among these and this is unlikely to change.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
In reply to this post by Viktor Dukhovni
On Mon, Jan 22, 2018 at 2:50 PM, Viktor Dukhovni
<[hidden email]> wrote:

>
>
>> On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users <[hidden email]> wrote:
>>
>> the problem is, that i cant change the cisco implementation :-(.
>
> YOU DO NOT need to change the Cisco implementation.
>
>> Cisco tell me, the capf implemtation is following all rfc documents.
>
> Nothing Cisco is telling you requires your issuing CA to have an
> extended key usage listing just "TLS Web Server Authentication".
>
>> If you are right,
>> i cant use any freeradius implementation, because there are based on
>> openssl. There is no option in freeradius, to ignore some think like this.
>
> Your problem is a misconfigured CA certificate.  Make sure your *CA*
> certificate has no extended key usage specified, OR has *all* the key
> usages specified that are required by any leaf certificate it will issue.

This is wrong. The CA is not misconfigured.

>> For my understanding, CA certificate may have these exteded keys - it's just
>> something out of the ordinary.
>
> The extended key usages on the CA are interpreted to LIMIT the key usages
> of certificates it can issue.  You can certainly use this extension, but
> then expect the CA to be invalid for key usages you did not list.

This is wrong. The KU and EKU bits are not interpreted that way.

Here's the standards OpenSSL claims to implement:
https://www.openssl.org/docs/standards.html.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 3:42 PM, Jeffrey Walton <[hidden email]> wrote:
>
>> Your problem is a misconfigured CA certificate.  Make sure your *CA*
>> certificate has no extended key usage specified, OR has *all* the key
>> usages specified that are required by any leaf certificate it will issue.
>
> This is wrong. The CA is not misconfigured.

You might say so, and yet, with more than just OpenSSL, the CA is not
suitable for issuing leaf certificates that are not included in its
extended key usage.  This is a de facto standard.

>>> For my understanding, CA certificate may have these exteded keys - it's just
>>> something out of the ordinary.
>>
>> The extended key usages on the CA are interpreted to LIMIT the key usages
>> of certificates it can issue.  You can certainly use this extension, but
>> then expect the CA to be invalid for key usages you did not list.
>
> This is wrong. The KU and EKU bits are not interpreted that way.

They plainly *are* interpreted in that way, just not by RFC5280, but
that's not the point.

> Here's the standards OpenSSL claims to implement:
> https://www.openssl.org/docs/standards.html.

So do many others, and yet when the RFC is impractical, a more practical
alternative is implemented.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
In reply to this post by OpenSSL - User mailing list


> On Jan 22, 2018, at 3:21 PM, Gladewitz, Robert via openssl-users <[hidden email]> wrote:
>
> Sorry, I did not mean to upset you.

I am not at all upset, just trying to be clear.

> Somehow I seem to have misunderstood something.

Yes.  Your CA has an EKU extension.  It should either not be present,
or list *all* the purposes for which the CA will issue leaf certificates.

If you're right (I don't think this is actually true) that the CA must
have "TLS Web Server Authentication" in its EKU (why?), then it must
also have at least "TLS Web Client Authentication", to allow the CA to
be used to authenticate TLS clients.

> The CAPF certificate is the CA certificate he goes for?
> Cisco states that this certificate requires both CA and
> the extended key "TLS Web Server Authentification"?

I bet that only the leaf certificate needs "TLS Web Server Authentification",
but if for some reason the CA certificate also needs "TLS Web Server Authentification"
then you'll need to also include "TLS Web Client Authentification" (in the
CA certificate).

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Viktor Dukhovni
> Here's the standards OpenSSL claims to implement:
    > https://www.openssl.org/docs/standards.html.
   
    So do many others, and yet when the RFC is impractical, a more practical
    alternative is implemented.
   
I did not see RFC 5280 in the list of the implemented/supported standards. (Yes I know, theoretically 5280 obsoletes and supersedes 3280 and 4630, but support of it isn’t claimed…)

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list

    > Here's the standards OpenSSL claims to implement:

Read the whole text.  It doesn’t say anything like “claims to implement.”


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
On Mon, Jan 22, 2018 at 9:01 PM, Salz, Rich via openssl-users
<[hidden email]> wrote:
>
>     > Here's the standards OpenSSL claims to implement:
>
> Read the whole text.  It doesn’t say anything like “claims to implement.”

My bad. Here's the corrected text:

    This page is a partial list of the specifications that are
relevant to OpenSSL

I don't see CA/Browser Forums listed, but I do see RFC 3280 listed.

And there are no notes on issuing polices, which is the matter at
hand. No reasonable person would expect OpenSSL to cite 61 RFCs,
including the IETF's PKIX RFCs, and not use PKIX issuing policies.

I'm befuddled someone thought and others agreed it was OK to break a
worldwide standard. The purpose of the standard is to ensure
interoperability. The break is a throwback to the verify=false days
for folks who needs things to "just work".

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
➢ I don't see CA/Browser Forums listed, but I do see RFC 3280 listed.
   
The page also says it’s “casually maintained.”  Feel free to create a PR on openssl/web repo. :)

IETF RFC’s aren’t perfect; that’s why there are errata.  Dragging this all the way to “we’re ignoring the words” is not nor accurate.  Someone who wants to argue that OpenSSL is doing the wrong thing here, should go to the IETF LAMPS WG and raise the issue.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
On Mon, Jan 22, 2018 at 9:27 PM, Salz, Rich <[hidden email]> wrote:
> ➢ I don't see CA/Browser Forums listed, but I do see RFC 3280 listed.
>
> The page also says it’s “casually maintained.”  Feel free to create a PR on openssl/web repo. :)
>
> IETF RFC’s aren’t perfect; that’s why there are errata.  Dragging this all the way to “we’re ignoring the words” is not nor accurate.  Someone who wants to argue that OpenSSL is doing the wrong thing here, should go to the IETF LAMPS WG and raise the issue.

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.

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.

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

Thank god Andy has not broken AES interop by whitening AES keys
because some people think it is a good idea.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
I think this discussion is getting a little hot and bothered.

Have a good night.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
In reply to this post by Jeffrey Walton-3


> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton <[hidden email]> 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.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
On Mon, Jan 22, 2018 at 10:04 PM, Viktor Dukhovni
<[hidden email]> wrote:

>
>
>> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton <[hidden email]> 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".

"Authority" as in governance and policies and procedures.

>> 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

Apples and oranges. Browsers use the CA/B baseline requirements.

What does it have to do the the IETF, the RFCs and PKIX?

> 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.

Yeah, the real world decision just decision just derailed the use of
crypto, not improve upon it.

I've seen this so many times in the past. It is the result of allowing
engineers drive requirements.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 10:15 PM, Jeffrey Walton <[hidden email]> wrote:
>
>> 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.
>
> Yeah, the real world decision just decision just derailed the use of
> crypto, not improve upon it.
>
> I've seen this so many times in the past. It is the result of allowing
> engineers drive requirements.

For the record:

The only change in OpenSSL 1.1.0 is that the EKU-based policy that oddly
applied only to untrusted certificates in 1.0.2 and earlier now applies
consistently whether the certificate comes from the trust store or the
remote peer.  I can demonstrate the issue with the OP's chain when only
the root CA is in the trust store:

$ openssl verify -CAfile ca2.pem -untrusted ca1.pem -purpose sslclient SEP64A0E714844E-L1.pem
SEP64A0E714844E-L1.pem: C = DE, ST = Sachsen, L = Leipzig, O = DBFZ Deutsches Biomasseforschungszentrum gGmbH, OU = IT, CN = CAPF-91d43ef6
error 26 at 1 depth lookup:unsupported certificate purpose

The "ca1.pem" file is the OP's intermediate CA, and the "ca2.pem" file is the OP's
root CA.  Repeating the same test with the purpose changed to "sslserver" works
as expected:

$ openssl verify -CAfile ca2.pem -untrusted ca1.pem -purpose sslserver SEP64A0E714844E-L1.pem
SEP64A0E714844E-L1.pem: OK

The only change in 1.1.0 is fixing a bug that resulted in inconsistent handling
of intermediate CAs depending on whether they were processed from the list
provided by the peer or from the trust store.

Restricting CA purpose based on EKU dates back to before 1.0.0.  You may not care,
but others may find this information useful.

Really over and out this time...

--
--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
123