- eap_tls: ERROR:
Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL
routines:tls_process_client_certificate:certificate verify failed
> On Jan 24, 2018, at 1:33 AM, Gladewitz, Robert via openssl-users
wrote:
>
> Nevertheless, a problem remains open for the Cisco CUCM users. If
> t
> On Jan 24, 2018, at 1:33 AM, Gladewitz, Robert via openssl-users
> wrote:
>
> Nevertheless, a problem remains open for the Cisco CUCM users. If these use
> the certificate internally signed by Cisco, the attributes are set as in the
> discussion and can not be subsequently adapted in our cas
[mailto:openssl-users-boun...@openssl.org] Im Auftrag von
Viktor Dukhovni
Gesendet: Dienstag, 23. Januar 2018 18:44
An: openssl-users@openssl.org
Betreff: Re: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR:
Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL
>> You seem to be very very VERY upset by how OpenSSL implements one
> particular part of RFC 5280. Viktor has shown that it’s not just us, it’s
> other code as well. The original poster was able to live with OpenSSL’s
> implementation. You don’t like that code. So be it.
> If tha
On Tue, Jan 23, 2018 at 4:33 PM, Salz, Rich wrote:
> On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich wrote:
> > ➢ The docs have _not_ changed:
> https://www.openssl.org/docs/standards.html.
> >
> > Nor is there any need for that page to change. READ WHAT IT SAYS.
>
> ➢ I'm surpr
On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich wrote:
> ➢ The docs have _not_ changed:
https://www.openssl.org/docs/standards.html.
>
> Nor is there any need for that page to change. READ WHAT IT SAYS.
➢ I'm surprised you are arguing against clear documentation on behaviors
On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich wrote:
> ➢ The docs have _not_ changed:
> https://www.openssl.org/docs/standards.html.
>
> Nor is there any need for that page to change. READ WHAT IT SAYS.
I'm surprised you are arguing against clear documentation on behaviors.
Jeff
--
openssl-
➢ The docs have _not_ changed: https://www.openssl.org/docs/standards.html.
Nor is there any need for that page to change. READ WHAT IT SAYS.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> On Jan 23, 2018, at 3:07 PM, Jeffrey Walton wrote:
>
> Your arguments are fallacious. How the browsers do things does not
> constitute the "de facto" standard. Your just begging the claim.
You're trolling. I'm no longer playing along, better things to do...
--
Viktor.
--
openssl-
On Tue, Jan 23, 2018 at 12:43 PM, Viktor Dukhovni
wrote:
>
>
>> On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users
>> wrote:
>>
>> Despite being wrong it is also absolutely irrelevant, because FreeRADIUS
>> retrieves the OpenSSL rejection of the cacert.capf.pem before any end-entit
> On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users
> wrote:
>
> Despite being wrong it is also absolutely irrelevant, because FreeRADIUS
> retrieves the OpenSSL rejection of the cacert.capf.pem before any end-entity
> certifcate is ever seen.
This is almost certainly not the c
On Sun, Jan 21, 2018 at 6:38 PM, Salz, Rich via openssl-users
wrote:
> ➢ The sensible thing at this point is to publish an update to RFC5280
> that accepts reality.
>
> Yes, and there’s an IETF place to do that if anyone is interested; see the
> LAMPS working group.
Related, the subject came
Dear helpful people,
The problem is now solved by a workaround based on a new CAPF certificate.
That is that.
Concerning the discussion here, i (representing my supervisor) would like to
pinpoint 2 facts that arouse:
First and foremost the attached cacert.capf.pem is based on a Cisco __System
ge
> On Jan 22, 2018, at 10:15 PM, Jeffrey Walton 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 languag
On Mon, Jan 22, 2018 at 10:04 PM, Viktor Dukhovni
wrote:
>
>
>> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton 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 au
> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton 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 els
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
On Mon, Jan 22, 2018 at 9:27 PM, Salz, Rich 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 t
➢ 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
On Mon, Jan 22, 2018 at 9:01 PM, Salz, Rich via openssl-users
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
> 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
> 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. (Y
> On Jan 22, 2018, at 3:21 PM, Gladewitz, Robert via openssl-users
> 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
> On Jan 22, 2018, at 3:42 PM, Jeffrey Walton 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
On Mon, Jan 22, 2018 at 2:50 PM, Viktor Dukhovni
wrote:
>
>
>> On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users
>> 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 i
OR: 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
> wrote:
>
> the problem is, that i cant change the cisco implementation :-(.
YOU DO
> On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users
> 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 telli
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
-
Von: openssl-users [mailto:openssl-users-boun...@openssl.org] Im Auftrag von
Viktor Dukhovni
Gesendet: Montag, 22. Januar 2018 17:01
An: openssl-users@openssl.org
Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR:
Failed in __FUNCTION__ (SSL_read): error:1417C08
> On Jan 22, 2018, at 1:57 AM, Gladewitz, Robert via openssl-users
> 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".
--
> On Jan 22, 2018, at 1:47 AM, Jeffrey Walton 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 be
El día lunes, enero 22, 2018 a las 06:40:22a. m. +, Gladewitz, Robert via
openssl-users escribió:
> Gladewitz, Robert möchte die Nachricht "[openssl-users] TLS Error in
> FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read):
> erro
-
Von: Jeffrey Walton [mailto:noloa...@gmail.com]
Gesendet: Montag, 22. Januar 2018 07:47
An: Gladewitz, Robert ; OpenSSL Users
Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed
in __FUNCTION__ (SSL_read): error:1417C086:SSL
On Mon, Jan 22, 2018 at 1:44 AM, Gladewitz, Robert via openssl-users
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 :-(.
>
, Rich via openssl-users
Gesendet: Montag, 22. Januar 2018 00:39
An: openssl-users@openssl.org
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
➢ The sensibl
Gladewitz, Robert möchte die Nachricht "[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" zurückrufen.
--
openssl-users mailing list
To unsubscr
] Im Auftrag von
Salz, Rich via openssl-users
Gesendet: Montag, 22. Januar 2018 00:39
An: openssl-users@openssl.org
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
➢ The sensible thing at this point is to publish an update to RFC5280
that accepts reality.
Yes, and there’s an IETF place to do that if anyone is interested; see the
LAMPS working group.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-user
On Sun, Jan 21, 2018 at 6:23 PM, Viktor Dukhovni
wrote:
>
>
>> On Jan 21, 2018, at 6:04 PM, Jeffrey Walton wrote:
>>
>> Maybe OpenSSL should allow users to choose between IETF issuing
>> policies and CA/Browser BR issuing policies.
>
> The sensible thing at this point is to publish an update to R
> On Jan 21, 2018, at 6:04 PM, Jeffrey Walton wrote:
>
> Maybe OpenSSL should allow users to choose between IETF issuing
> policies and CA/Browser BR issuing policies.
The sensible thing at this point is to publish an update to RFC5280
that accepts reality.
--
Viktor.
--
openssl-us
On Sun, Jan 21, 2018 at 5:59 PM, Viktor Dukhovni
wrote:
>
>
>> On Jan 21, 2018, at 2:40 PM, Jeffrey Walton wrote:
>>
>>> OpenSSL interprets the "extendedKeyUsage" extension in CA certificates
>>> as a restriction on the allowed extended key usages of leaf certificates
>>> that can be issued by th
> On Jan 21, 2018, at 2:40 PM, Jeffrey Walton wrote:
>
>> OpenSSL interprets the "extendedKeyUsage" extension in CA certificates
>> as a restriction on the allowed extended key usages of leaf certificates
>> that can be issued by that CA.
>>
>> You should typically not specify extended key usa
On Sun, Jan 21, 2018 at 1:31 PM, Viktor Dukhovni
wrote:
>
> ...
> OpenSSL interprets the "extendedKeyUsage" extension in CA certificates
> as a restriction on the allowed extended key usages of leaf certificates
> that can be issued by that CA.
>
> You should typically not specify extended key usa
> On Jan 21, 2018, at 7:34 AM, Gladewitz, Robert via openssl-users
> wrote:
>
> If I understand your right, then I need to add "TLS Web Client Authentication"
> to the CAPF certificate.
Or better still, remove the "ExtendedKeyUsage" extension from the CA
certificate and thus specify neither "
sl-users@openssl.org
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 20, 2018, at 6:42 AM, Gladewitz, Robert via openssl-users
> wrote:
> On Jan 20, 2018, at 6:42 AM, Gladewitz, Robert via openssl-users
> wrote:
>
> Hello Vikor,
>
> hmm, we have only a self signed root ca and the CAPF ist directly minor. And
> the extended key usage is mandodary by cisco.
>
> You mean, the only solution are, the the root ca also have the s
- eap_tls: ERROR:
Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL
routines:tls_process_client_certificate:certificate verify failed
Hi Robert,
Lets see if I get it right. Please correct me if I am misinterpreting.
If an extended key usage extension such as "TLS Web Server Authenticatio
in __FUNCTION__ (SSL_read): error:1417C086:SSL
routines:tls_process_client_certificate:certificate verify failed
Viktor Dukhovni wrote:
>> On Jan 19, 2018, at 10:09 PM, Frank Migge wrote:
>>
>>>> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication
>>
&g
[mailto:openssl-users-boun...@openssl.org] Im Auftrag von
Viktor Dukhovni
Gesendet: Samstag, 20. Januar 2018 05:34
An: openssl-users@openssl.org
Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed
in __FUNCTION__ (SSL_read): error:1417C086:SSL
Viktor Dukhovni wrote:
>> On Jan 19, 2018, at 10:09 PM, Frank Migge wrote:
>>
Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication
>>
>> This is were I would check first.
>>
>> I am not fully sure, but believe that Extended Key Usage should *not* be
>> there.
>
> Indeed the
(SSL_read): error:1417C086:SSL
routines:tls_process_client_certificate:certificate verify failed
Hi Robert,
error 26 : unsupported certificate purpose
It seems the cert gets declined because of a problem with cert
extensions. "keyUsage" or "extendedKeyUsage" are ty
> On Jan 19, 2018, at 10:09 PM, Frank Migge wrote:
>
> >> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication
>
> This is were I would check first.
>
> I am not fully sure, but believe that Extended Key Usage should *not* be
> there.
Indeed the intermediate CA should either
...@dbfz.de>"
>
> (69) eap_tls: TLS-Cert-Common-Name := "CAPF-91d43ef6"
>
> (69) eap_tls: ERROR: SSL says error 26 : unsupported certificate purpose
>
> (69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal
> unsupported_certificate
>
>
Hi Robert,
>> error 26 : unsupported certificate purpose
It seems the cert gets declined because of a problem with cert
extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In
your case, the leaf certificate "CAPF-91d43ef6" has two extensions:
Object 00: X509v3 Key Usage
Digita
SSL says error 26 : unsupported certificate purpose
(69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal
unsupported_certificate
(69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate
tls: TLS_accept: Error in error
(69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_rea
No, SSL_accept() definitively returns 1 (I check it through debugger, that is
where strangeness comes).
--
View this message in context:
http://www.nabble.com/SSL_read-error-t1586584.html#a4313659
Sent from the OpenSSL - User forum at Nabble.com
Hello,
> I get the strange error140DF114:SSL routines:SSL_read:uninitialized ,
> though I have initialized the connection (accept completes successfully).
Maybe SSL_accept() did not return 1 but 0 which is not success.
Checking return code with something like that:
if ( SSL_accept() <
Hi everybody,
I get the strange error140DF114:SSL routines:SSL_read:uninitialized ,
though I have initialized the connection (accept completes successfully).
Has anybody encountered the same problem ???
Thanks,
Molex.
--
View this message in context:
http://www.nabble.com/SSL_read-error
58 matches
Mail list logo
