Strange problem with openssl

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange problem with openssl

Paul Schmehl
I'm running FreeBSD 10.3-RELEASE with # openssl version
OpenSSL 1.0.1s-freebsd  1 Mar 2016

This is the FreeBSD base version of openssl, not the ports version. I have
ssh access to the server and can sudo to root.

Please note: In the error messages below, I have removed some of the
pathing so as not to reveal the exact locations on the server.

I have two problems. When I use https with an rss reader module in Joomla,
I get this error: Warning: fopen(): SSL operation failed with code 1.
OpenSSL Error messages: error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed in
/Sites/www.vvfh.org/libraries/joomla/filesystem/file.php on line 335
Warning: fopen(): Failed to enable crypto in
/Sites/www.vvfh.org/libraries/joomla/filesystem/file.php on line 335
Warning: fopen(https://blog.vvfh.org/feed/rss2): failed to open stream:
operation failed in
/Sites/www.vvfh.org/libraries/joomla/filesystem/file.php on line 335

I've worked around this problem by not forcing https on the blog. That way
the module can read the rss feed without encryption. The blog works without
SSL and with SSL, and I force SSL for logins.

I had someone test the feed from a different server, and it worked fine
with SSL, so the problem appears to be isolated to this server.

The second problem occurs when I try to run some commandline python
scripts, I get this error: requests.exceptions.ConnectionError:
HTTPSConnectionPool(host='wiki.vvfh.org', port=443): Max retries exceeded
with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL
routines', 'ssl3_get_server_certificate', 'certificate verify
failed')],)",),))
<class 'requests.exceptions.ConnectionError'>

Both of them appear to be related to how openssl handles ssl sessions.

When I run openssl s_client -connect wiki.vvfh.org:443, I get the following
error:  Verify return code: 18 (self signed certificate)

This is very odd, because ssllabs.com scores the site as an A, and says the
chain is intact, no missing parts. Yet, for some reason, ssl doesn't see it
that way. Furthermore, it sees the certs as self-signed, which makes no
sense at all. I'm using a wildcard cert (Comodo) for three sites: www, wiki
and blog - all in the vvfh.org domain.

Even more confusing, if I verify the cert from the commandline, openssl
says it's OK.
openssl verify -untrusted
comodo-rsa-domain-validation-sha-2-w-root.ca-bundle STAR_vvfh_org.crt
STAR_vvfh_org.crt: OK

If I verify the cert without the chain, I get an error:
openssl verify STAR_vvfh_org.crt
STAR_vvfh_org.crt: OU = Domain Control Validated, OU = PositiveSSL
Wildcard, CN = *.vvfh.org
error 20 at 0 depth lookup:unable to get local issuer certificate

This is my apache (2.4) config:
 # Enable SSL
    SSLEngine On
    SSLProtocol         all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    SSLHonorCipherOrder on
    SSLCertificateFile /webcerts/STAR_vvfh_org.crt
    SSLCertificateKeyFile /webcerts/STAR.vvfh.org.key
    SSLCACertificateFile
/webcerts/COMODORSADomainValidationSecureServerCA.crt
    SSLCertificateChainFile
/webcerts/comodo-rsa-domain-validation-sha-2-w-root.ca-bundle

I've been working around the problem, but I'd like to figure it out and get
it fixed.

"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl ([hidden email])
Independent Researcher
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange problem with openssl

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Paul Schmehl
> Sent: Thursday, November 09, 2017 20:09
> To: [hidden email]
> Subject: [openssl-users] Strange problem with openssl
>
> When I run openssl s_client -connect wiki.vvfh.org:443, I get the following
> error:  Verify return code: 18 (self signed certificate)
>
> This is very odd, because ssllabs.com scores the site as an A, and says the
> chain is intact, no missing parts. Yet, for some reason, ssl doesn't see it
> that way. Furthermore, it sees the certs as self-signed, which makes no
> sense at all.

It sees *a* certificate as self-signed. And indeed there is one. You're sending the entire chain, including the root. By definition, the root is self-signed.

So s_client is saying: I'm verifying the chain from the server, and I got to the point where I found a self-signed certificate (which is the same as saying "I found a root certificate").

OpenSSL isn't contradicting ssllabs. s_client reports the whole chain is there.

> Even more confusing, if I verify the cert from the commandline, openssl
> says it's OK.
> openssl verify -untrusted
> comodo-rsa-domain-validation-sha-2-w-root.ca-bundle STAR_vvfh_org.crt
> STAR_vvfh_org.crt: OK

s_client isn't saying the certificate isn't OK. It's saying it received a root certificate from the server.

You didn't give s_client any trust anchors to verify the chain. So it's going to walk the whole chain, and it's going to find the root, and it's going to complain about that.

Programs don't normally send the root certificate, on the grounds that if the peer doesn't already have it, they're not going to trust it anyway. But it's not forbidden.

Try this:

1. Run "openssl s_client -connect wiki.vvfh.org:443 -showcerts". Copy the last certificate in the output (which will be the root) and paste it into tmp.pem.
2. Run " openssl s_client -connect wiki.vvfh.org:443 -verify 2 -CAfile tmp.pem". No complaint from s_client now.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


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

Re: Strange problem with openssl

Paul Schmehl
--On November 10, 2017 at 4:33:41 PM +0000 Michael Wojcik
<[hidden email]> wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of Paul Schmehl
>> Sent: Thursday, November 09, 2017 20:09
>> To: [hidden email]
>> Subject: [openssl-users] Strange problem with openssl
>>
>> When I run openssl s_client -connect wiki.vvfh.org:443, I get the
>> following error:  Verify return code: 18 (self signed certificate)
>>
>> This is very odd, because ssllabs.com scores the site as an A, and says
>> the chain is intact, no missing parts. Yet, for some reason, ssl doesn't
>> see it that way. Furthermore, it sees the certs as self-signed, which
>> makes no sense at all.
>
> It sees *a* certificate as self-signed. And indeed there is one. You're
> sending the entire chain, including the root. By definition, the root is
> self-signed.
>
> So s_client is saying: I'm verifying the chain from the server, and I got
> to the point where I found a self-signed certificate (which is the same
> as saying "I found a root certificate").
>
> OpenSSL isn't contradicting ssllabs. s_client reports the whole chain is
> there.
>

Thanks for clearing that up, Michael.

>> Even more confusing, if I verify the cert from the commandline, openssl
>> says it's OK.
>> openssl verify -untrusted
>> comodo-rsa-domain-validation-sha-2-w-root.ca-bundle STAR_vvfh_org.crt
>> STAR_vvfh_org.crt: OK
>
> s_client isn't saying the certificate isn't OK. It's saying it received a
> root certificate from the server.
>
> You didn't give s_client any trust anchors to verify the chain. So it's
> going to walk the whole chain, and it's going to find the root, and it's
> going to complain about that.
>
> Programs don't normally send the root certificate, on the grounds that if
> the peer doesn't already have it, they're not going to trust it anyway.
> But it's not forbidden.
>
> Try this:
>
> 1. Run "openssl s_client -connect wiki.vvfh.org:443 -showcerts". Copy the
> last certificate in the output (which will be the root) and paste it into
> tmp.pem. 2. Run " openssl s_client -connect wiki.vvfh.org:443 -verify 2
> -CAfile tmp.pem". No complaint from s_client now.

You are correct. Thanks for clarifying this.

Do you have any thoughts on why I'm getting the errors when trying to
connect to the rss2 feed or the commandline issue with python?

"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl ([hidden email])
Independent Researcher
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange problem with openssl

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Paul Schmehl
> Sent: Friday, November 10, 2017 11:59
> To: [hidden email]
> Subject: Re: [openssl-users] Strange problem with openssl
>
> Do you have any thoughts on why I'm getting the errors when trying to
> connect to the rss2 feed or the commandline issue with python?

All we have from the rss2 issue is a generic complaint about verifying the server's certificate chain, so it's really hard to say. The module you're using either doesn't provide good diagnostics, or it's putting them somewhere other than stderr.

It's possible that the module is configuring OpenSSL to not allow wildcard certificates. It's possible that it doesn't have the Comodo root in its trust collection. I'm not offhand seeing any other problems with the certs, though I certainly didn't try to check every possibility. The openssl verify commands you ran will have tested a number of the possible reasons for rejection, but not all of them. (There are options to test other things, but that gets complicated, too; you don't know what checks your failing applications are making.)

The Python issue looks like it's probably the same thing, whatever that thing may be. It's also complaining about certificate verification.

If you can get either of those clients to provide more detailed diagnostics, we might be able to narrow it down. Or someone else on the list might have a better idea.

Certificate validation with the public Internet X.509 PKI hierarchy is a nightmare, to be honest. (Ivan Ristic's /Bulletproof TLS/ book discusses many of the problems; the Cypherpunks presentation "X.509 PKI: The OSI of a New Generation" is another good source.) There are a zillion things that can go wrong, and it's often very difficult to figure out why some particular application is unhappy.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



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

Re: Strange problem with openssl

Paul Schmehl
--On November 10, 2017 at 5:21:25 PM +0000 Michael Wojcik
<[hidden email]> wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of Paul Schmehl
>> Sent: Friday, November 10, 2017 11:59
>> To: [hidden email]
>> Subject: Re: [openssl-users] Strange problem with openssl
>>
>> Do you have any thoughts on why I'm getting the errors when trying to
>> connect to the rss2 feed or the commandline issue with python?
>
> All we have from the rss2 issue is a generic complaint about verifying
> the server's certificate chain, so it's really hard to say. The module
> you're using either doesn't provide good diagnostics, or it's putting
> them somewhere other than stderr.
>
> It's possible that the module is configuring OpenSSL to not allow
> wildcard certificates. It's possible that it doesn't have the Comodo root
> in its trust collection. I'm not offhand seeing any other problems with
> the certs, though I certainly didn't try to check every possibility. The
> openssl verify commands you ran will have tested a number of the possible
> reasons for rejection, but not all of them. (There are options to test
> other things, but that gets complicated, too; you don't know what checks
> your failing applications are making.)
>
> The Python issue looks like it's probably the same thing, whatever that
> thing may be. It's also complaining about certificate verification.
>
> If you can get either of those clients to provide more detailed
> diagnostics, we might be able to narrow it down. Or someone else on the
> list might have a better idea.
>
> Certificate validation with the public Internet X.509 PKI hierarchy is a
> nightmare, to be honest. (Ivan Ristic's /Bulletproof TLS/ book discusses
> many of the problems; the Cypherpunks presentation "X.509 PKI: The OSI of
> a New Generation" is another good source.) There are a zillion things
> that can go wrong, and it's often very difficult to figure out why some
> particular application is unhappy.
>

Thanks again for your detailed response, Michael. WRT the RSS issue, the
vendor was able to view the feed over https without any errors, using the
same software that I'm using (Joomla 3.8.2 and Simple RSS Feed Reader (by
JoomlaWorks) 3.5). So, that seems to point to a problem unique to my server.

The python problem I may be able to enable debug on and see if any
additional detail is helpful. I'll check in to that.

> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus



"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl ([hidden email])
Independent Researcher
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users