> From: Felipe Gasper
> Sent: Thursday, 3 November, 2022 10:43
> >
> > And your description looks wrong anyway: shutdown(SHUT_RD) has
> > implementation-defined behavior for TCP sockets (because TCP does not
> > announce the read side of half-close to the peer), and on Linux causes
> > blocked rec
> On Nov 3, 2022, at 11:37, Michael Wojcik via openssl-users
> wrote:
>
>> It’s a rare
>> issue, but when it does it’s a head-scratcher. To avoid that, it’s necessary
>> to shutdown(SHUT_RD) then drain the read buffer before close().
>
> Well, it's not *necessary* to do a half-close. Applicat
> From: Felipe Gasper
> Sent: Thursday, 3 November, 2022 08:51
>
> You probably know this, but: On Linux, at least, if a TCP socket close()s
> with a non-empty read buffer, the kernel sends TCP RST to the peer.
Yes, that's a conditional-compliance (SHOULD) requirement from the Host
Requirements
> On Nov 3, 2022, at 10:17, Michael Wojcik via openssl-users
> wrote:
>
>> Does OpenSSL’s documentation mention that? (I’m not exhaustively
>> familiar with it, but I don’t remember having seen such.)
>
> I doubt it. I don't see anything on the wiki, and this is a pretty obscure
> issue, all
otify-close) is legitimate, OpenSSL could
> gainfully tolerate/hide the EPIPE that that close() likely produces, and have
> SSL_read() et al just return empty-string.
Well, it could, but OpenSSL generally doesn't try to provide that type of
abstraction.
Also note this paragraph from
it, but I don’t remember having seen such.)
It almost seems like, given that TLS notify-close then TCP close() (i.e.,
without awaiting the peer’s TLS notify-close) is legitimate, OpenSSL could
gainfully tolerate/hide the EPIPE that that close() likely produces, and have
SSL_read() et al just r
> From: Felipe Gasper
> Sent: Wednesday, 2 November, 2022 12:46
>
> I wouldn’t normally expect EPIPE from a read operation. I get why it happens;
> it just seems odd. Given that it’s legitimate for a TLS peer to send the
> close_notify and then immediately do TCP close, it also seems like EPIPE i
> On Oct 26, 2022, at 13:34, Michael Wojcik via openssl-users
> wrote:
>
>> From: openssl-users On Behalf Of Felipe
>> Gasper
>> Sent: Wednesday, 26 October, 2022 11:15
>>
>> I’m seeing that OpenSSL 3, when it reads empty on a socket, sends some
>> sort of response, e.g.:
>>
>> -
> From: openssl-users On Behalf Of Felipe
> Gasper
> Sent: Wednesday, 26 October, 2022 11:15
>
> I’m seeing that OpenSSL 3, when it reads empty on a socket, sends some
> sort of response, e.g.:
>
> - before read
> [pid 42417] read(7276781]>, "", 5) = 0
> [pid 42417] sendmsg(7276781]>,
Hello,
I’m seeing that OpenSSL 3, when it reads empty on a socket, sends some
sort of response, e.g.:
- before read
[pid 42417] read(7276781]>, "", 5) = 0
[pid 42417] sendmsg(7276781]>, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\0022", iov_len=2}], msg_iovlen=1,
msg_contro
message. So you are
getting a network-stack timeout on a sockets operation; this isn't a TLS
protocol issue or anything else at a level above the network stack.
> We also call the ERR_print_errors(bio); but it displays a blank line. We call
> ERR_clear_error() before the SSL_read as me
> From: Kamala Ayyar
> Sent: Monday, 23 August, 2021 09:22
> We get the SSL_ERROR_SYSCALL from SSL_Read and SSL_Write quite often.
You'll get SSL_ERROR_SYSCALL any time OpenSSL makes a system call (including,
on Windows, a Winsock call) and gets an error.
> It seems the
clients without issues.
* The application logic is to keep trying to connect every timeout.
* After maybe a few hours/days we see the clients dropping
connections. The logs indicate the SSL_Read or SSL_Write on the
Server fails for a client with SSL_Error number 5
(SSL_ERROR_SYSCALL
the same inport fort for the clients. We did get CLIENT_WAIT
and TIME_WAIT states once on a while using the netstat commands but most
times the connections were ESTABLISHED.
We get the SSL_ERROR_SYSCALL from SSL_Read and SSL_Write quite often. We
never got this error while using the SSL_connect
nections. The
> logs
> indicate the SSL_Read or SSL_Write on the Server fails for a client with
> SSL_Error
> number 5 (SSL_ERROR_SYSCALL) and the equivalent Windows error of WSATimeOut.
> We
> then observe the WSAECONNRESET as the Client closed connection. We see this
> behav
) and clients without issues.
* The application logic is to keep trying to connect every timeout.
* After maybe a few hours/days we see the clients dropping connections.
The logs indicate the SSL_Read or SSL_Write on the Server fails for a client
with SSL_Error number 5 (SSL_ERROR_SYSCALL
On Wed, Dec 11, 2019 at 04:36:20PM +0530, Raja Ashok wrote:
> A TLS server application spawns 2 thread and handles 'n' number of TLS
> clients. All connections SSL_read operations are performed on one thread
> and SSL_write on another thread. To achieve this curren
Hi All,
A TLS server application spawns 2 thread and handles 'n' number of TLS
clients. All connections SSL_read operations are performed on one thread
and SSL_write on another thread. To achieve this currently I lock the `SSL`
connection handle. This application uses TLSv1.2 and TL
On Behalf Of John
Unsworth
Sent: 07 May 2019 09:06
To: openssl-users@openssl.org
Subject: RE: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN
CAUTION: This email originated from outside of Synchronoss.
Thanks, the mutex is tied to the SSL session and used for all calls (now!).
The
Thanks, the mutex is tied to the SSL session and used for all calls (now!).
The good news is that moving SSL_get_error() into the same mutex unit as
SSL_read() has solved the problem.
Thank you for all your help and advice.
Regards,
John.
John Unsworth |Meta-Directory Engineering and Support
On Fri, May 03, 2019 at 09:34:14AM +, John Unsworth wrote:
> Testing changed code.
For the record, though I think you realise this, *both* the SSL_read()
or SSL_write() and the following SSL_get_error() need to be protected
as a unit by the *same* instance of the locked mutex. It would
Testing changed code.
Regards
John
From: openssl-users on behalf of Matt
Caswell
Sent: Friday, May 3, 2019 10:16 am
To: openssl-users@openssl.org
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN
CAUTION: This email originated from
On 02/05/2019 18:23, Viktor Dukhovni wrote:
>>> At this point you'd be calling SSL_get_error(), is there a lock that
>>> prevents writes between SSL_read() and SSL_read() and SSL_get_error()?
>>
>> The mutex does not protect SSL_get_error() calls.
>
>
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN
CAUTION: This email originated from outside of Synchronoss.
On Thu, May 02, 2019 at 04:10:31PM +, John Unsworth wrote:
> > Do you wait for the non-blocking connect to complete at this point?
> We connect in blocking
> At this point you'd be calling SSL_get_error(), is there a lock that
> > prevents writes between SSL_read() and SSL_read() and SSL_get_error()?
>
> The mutex does not protect SSL_get_error() calls.
I think that's an application bug. The SSL_get_error() is using
t
rming reads?
What is the granularity of the relevant locks?
The mutex only allows one SSL call at a time.
> At this point you'd be calling SSL_get_error(), is there a lock that prevents
> writes between SSL_read() and SSL_read() and SSL_get_error()?
The mutex does not protect SSL_get
thread that reads LDAP results.
How are further requests locked out when you're performing reads?
What is the granularity of the relevant locks?
> If an operation is outstanding then the result thread does (simplified):
>
> SSL_read()
> If > 0 return data.
At this point you&
Caswell
Sent: 01 May 2019 08:42
To: openssl-users@openssl.org
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
CAUTION: This email originated from outside of Synchronoss.
On 30/04/2019 23:37, Viktor Dukhovni wrote:
> On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wr
thread does (simplified):
SSL_read()
If > 0 return data.
Else if SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE then poll(); back to
SSL_read() when data available.
Else return error and disconnect.
Don't know what protocol was negotiated or what the server does in terms of
returned data. TCP
On 30/04/2019 23:37, Viktor Dukhovni wrote:
> On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote:
>
>>> Is the handshake explicit, or does the application just call
>>> SSL_read(), with OpenSSL performing the handshake as needed?
>>
>> I occasion
This is what we do:
Create a non-blocking TCP socket.
Call SSL_new(), SSL_set_fd(), SSL_connect()
Thereafter call SSL_read().
Renegotiates handled by OpenSSL.
We have only seen the error very occasionally, the vast majority of calls
return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
The
> On May 1, 2019, at 9:47 AM, John Unsworth
> wrote:
>
> Create a non-blocking TCP socket.
> Call SSL_new(), SSL_set_fd(), SSL_connect()
> Thereafter call SSL_read().
> Renegotiates handled by OpenSSL.
Can you be more specific about "Create a non-blocking TCP socke
This is what we do:
Create a non-blocking TCP socket.
Call SSL_new(), SSL_set_fd(), SSL_connect()
Thereafter call SSL_read().
Renegotiates handled by OpenSSL.
We have only seen the error very occasionally, the vast majority of calls
return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
The
>-- Original Message --
>
>
>>-- Original Message --
>>
>>On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote:
>>
>>> >Is the handshake explicit, or does the application just call
>>> >SSL_read(), with OpenSSL performing the hand
>-- Original Message --
>
>On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote:
>
>> >Is the handshake explicit, or does the application just call
>> >SSL_read(), with OpenSSL performing the handshake as needed?
>>
>> I occasionally (somewhat
On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote:
> >Is the handshake explicit, or does the application just call
> >SSL_read(), with OpenSSL performing the handshake as needed?
>
> I occasionally (somewhat rarely) see the issue mentioned by the OP.
> Ignoring
return
>SSL_ERROR_WANT_READ when the network bio signals a retriable
>failure.
>
>The OP has not provided much detail about the connections in
>question are created. Is the connection made by the
>application, and SSL negotiated over an existing socket, or
>is the connection e
tablished by OpenSSL over a "connect bio"?
Is the handshake explicit, or does the application just call
SSL_read(), with OpenSSL performing the handshake as needed?
In any case, I would not expect SSL_ERROR_SYSCALL under normal
conditions. The documentation says:
SSL_ERROR_SYSC
> From: openssl-users on behalf of John
> Unsworth
> Sent: Monday, April 29, 2019 10:54
> We are using OpenSSL 1.1.0h on Linux to send operations to LDAP servers. We
> use SSL_read()
> to receive the replies on a non-blocking socket. The vast majority of times
> S
> On Apr 30, 2019, at 12:21 PM, Michael Wojcik
> wrote:
>
>> From: openssl-users on behalf of Felipe
>> Gasper
>> Sent: Tuesday, April 30, 2019 11:06
>
>> My question is, does TLS allow a client to be _able_ to parse an incomplete
>> message?
>> Or is it that only the entire message can
> From: openssl-users on behalf of Felipe
> Gasper
> Sent: Tuesday, April 30, 2019 11:06
> My question is, does TLS allow a client to be _able_ to parse an incomplete
> message?
> Or is it that only the entire message can be decoded?
TLS doesn't have the concept of a "message". It has record
Hello,
I’ve got an OpenSSL client that’s showing the behavior in strace:
read 5 bytes - OK
read 11228 bytes - gets partial response
read remainder - ECONNRESET
That ECONNRESET causes OpenSSL to fail the entire SSL_read().
My question is, does TLS allow a client to be
We are using OpenSSL 1.1.0h on Linux to send operations to LDAP servers. We use
SSL_read() to receive the replies on a non-blocking socket. The vast majority
of times SSL_read() returns >0, SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE as
per the spec. However we are very occasionally see
shutdown()
> >>>> called from callbacks could be deferred until a more favourable time.
> >> In this case, it's an SSL_read() that invoked the callback, though
> >> probably not relevant.
> >>
> >> And actually, no deferal would be necessary,
ut to return
from the SSL_accept() that invoked the callback. That is SSL_shutdown()
called from callbacks could be deferred until a more favourable time.
In this case, it's an SSL_read() that invoked the callback, though
probably not relevant.
And actually, no deferal would be necessary, I l
t to return
>>> from the SSL_accept() that invoked the callback. That is SSL_shutdown()
>>> called from callbacks could be deferred until a more favourable time.
>
> In this case, it's an SSL_read() that invoked the callback, though
> probably not relevant.
>
nvoked the callback. That is SSL_shutdown()
> > called from callbacks could be deferred until a more favourable time.
In this case, it's an SSL_read() that invoked the callback, though
probably not relevant.
And actually, no deferal would be necessary, I looks to me that the
info callbac
On 15/02/2019 20:32, Viktor Dukhovni wrote:
>> On Feb 15, 2019, at 12:11 PM, Sam Roberts wrote:
>>
>> In particular, I'm getting a close_notify alert, followed by two
>> NewSessionTickets from the server.
>>
>> The does SSL_read()/SSL_get_error(), it is
> On Feb 15, 2019, at 12:11 PM, Sam Roberts wrote:
>
> In particular, I'm getting a close_notify alert, followed by two
> NewSessionTickets from the server.
>
> The does SSL_read()/SSL_get_error(), it is returning
> SSL_ERROR_ZERO_RETURN, so I stop calling SSL_read()
ticular, I'm getting a close_notify alert, followed by two
> NewSessionTickets from the server.
This sounds like a bug somewhere. Once you have close_notify you shouldn't
expect anything else. Is that an OpenSSL server?
Matt
>
> The does SSL_read()/SSL_get_error(), it is
Resending, I just got banned for "bounces", though why gmail would be
bouncing I don't know.
On Thu, Feb 14, 2019 at 2:51 PM Sam Roberts wrote:
In particular, I'm getting a close_notify alert, followed by two
NewSessionTickets from the server.
The does SSL_read()/SS
On 14/02/2019 22:51, Sam Roberts wrote:
> In particular, I'm getting a close_notify alert, followed by two
> NewSessionTickets from the server.
This sounds like a bug somewhere. Once you have close_notify you shouldn't
expect anything else. Is that an OpenSSL server?
Matt
--
openssl-users mai
In particular, I'm getting a close_notify alert, followed by two
NewSessionTickets from the server.
The does SSL_read()/SSL_get_error(), it is returning
SSL_ERROR_ZERO_RETURN, so I stop calling SSL_read().
However, that means that the NewSessionTickets aren't seen, so I don't
ge
re processed, there's
> an expectation of additional application_data, but no hint that more
> application_data will be forthcoming.
> 2) Pending bytes - There is an incomplete record that needs processing.
> Additional data should be fed into the BIO.
If you call SSL_read() an
>> If no application data is available then you get the -1 (for SSL_read()) or
>> 0 (for SSL_read_ex()) return code. You also get that return code for other
>> types of issues, and you are supposed to call SSL_get_error() to interpret
>> it.
>
> In this
> On 23/01/2019 14:04, Arran Cudbard-Bell wrote:
>> I'm working with wpa_supplicant to try and fix up its EAP-TTLS and EAP-PEAP
>> implementations to work correctly with TLS 1.3 and session tickets.
>>
>> Where a new_session_ticket message is sent after client/ser
On 23/01/2019 14:04, Arran Cudbard-Bell wrote:
> I'm working with wpa_supplicant to try and fix up its EAP-TTLS and EAP-PEAP
> implementations to work correctly with TLS 1.3 and session tickets.
>
> Where a new_session_ticket message is sent after client/server finish, ca
I'm working with wpa_supplicant to try and fix up its EAP-TTLS and EAP-PEAP
implementations to work correctly with TLS 1.3 and session tickets.
Where a new_session_ticket message is sent after client/server finish, calls to
SSL_read() result in the new_session_ticket message being proc
be able to call
> SSL_write() to send its own data to the other side.
>
> My code currently does this using non-blocking I/O like this:
>
> 1. If the underlying socket is not readable go to #2 immediately to
> be
>able to send data. If the socket is reported to be readable, c
The connection is open for verly long time (>24h), so I thought that
the peer may force a renogatioation due to the session timeout. Or
have I got something wrong and a renogatioation is not necessary for
long-running sessions?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/
>The code above does what I want - except for renegotiations!
Do you absolutely, positively, HAVE TO support renegotiation?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
using non-blocking I/O like this:
1. If the underlying socket is not readable go to #2 immediately to be
able to send data. If the socket is reported to be readable, call
SSL_read() to get that data. If that call cannot be completed due
to SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE, poll the
The TLS protocol puts limits on how much application data can appear in a
single record. Without knowing all the details, that seems like a very silly
requirement. There is no security reason for it.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl
ecified file to
> server for that i am using SSL_write(). i can achieve this using SSL_write()
> in a while loop but my requirement is i have to use single SSL_write() for
> sending whole content of file and single SSL_read at the server to receive
> the whole content of the file.becaus
SSL_write() in a while loop but my requirement is i have to use single
SSL_write() for sending whole content of file and single SSL_read at the
server to receive the whole content of the file.because in that message
itself we have to specify some id so that it can be identified at the
server to
- 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
1 - 100 of 522 matches
Mail list logo
