[openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine

[Quanah Gibson-Mount]

--On Thursday, August 25, 2016 12:36 AM +0000 Viktor Dukhovni 
<openssl-users at dukhovni.org> wrote:

> On Wed, Aug 24, 2016 at 11:17:21PM +0000, Quanah Gibson-Mount via RT
> wrote:
>
>> When a process (nginx in this case) has this as the server cert, it core
>> dumps with an abort() when clients request the cert:
>
> You say the server dumps core, and yet:
>
>> # 1  0x00007f22ba125ce8 in __GI_abort () at abort.c:90
>> [...]
>> # 14 0x00007f22bac435ec in d2i_X509 (a=a at entry=0x0,
>> in=in at entry=0x7ffc53c49a60, len=len at entry=1517) at x_x509.c:143
>> # 15 0x00007f22baf71da2 in ssl3_get_server_certificate
>> # (s=s at entry=0x2167a50)
>> at s3_clnt.c:1228
>> # 16 0x00007f22baf76cee in ssl3_connect (s=0x2167a50) at s3_clnt.c:345
>> # 17 0x00007f22baf8166e in ssl23_get_server_hello (s=0x2167a50) at
>> s23_clnt.c:799
>> # 18 ssl23_connect (s=0x2167a50) at s23_clnt.c:228
>
> this is clearly a TLS client-side stack trace.  Why is nginx acting
> as an SSL/TLS client?

It's a proxy server... so it's proxying between the client connecting to 
nginx on the IMAPS port and the jetty server on the other side.

so:

end user <-> nginx:143 <-> jetty:7143

The issue only happens when proxying IMAP on port 143 with startTLS or 993 
(IMAPS).  It does not occur on POP w/ starttls or web traffic (443).  It 
also is only happening with this one particular client, as we have numerous 
customers (and our own setup) not experiencing this issue.

I'll have them supply what's in their keystore that Jetty's using as well.

--Quanah


--

Quanah Gibson-Mount