Warning: no valid certs found cafile stream: `/etc/letsencrypt/live/ ...etc

Help
#1

My domain is: enfeedia.com

I ran this command:
$fhandle = fopen('https://enfeedia.com/enfeedia.xml', 'r')
permissions for that file is 775.
That xml file is an RSS compliant feed, proven over and over, including working with Google FeedBurner.

It produced this output:
Warning : no valid certs found cafile stream: `/etc/letsencrypt/live/enfeedia.com/' in /srv/www/enfeedia.com/public_html/... {omitted remainder of path to the test script, which includes only that fopen() command, isolating the test from all my website code}

My web server is (include version): CentOS Linux release 7.8.2003 (Core)

The operating system my web server runs on is (include version):
Server version: Apache/2.4.6 (CentOS)
Server built: Apr 2 2020 13:13:23

My hosting provider, if applicable, is: Linode

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 1.6.0

Notes:

I (obviously) keep certs renewed on time.

During my various experiments, I decided to do a forced renewal. It was successful and had no impact on test results.

In php.ini, both "allow_url_open" and "allow_url_include" are "On".

In php.ini, this line is included (not commented out):
openssl.cafile=/etc/letsencrypt/live/enfeedia.com/
Yes, I know to reboot after changes to php.ini.

Permissions of the four .pem files -- cert.pem, chain.pem, full chain.pem and privkey.pem -- are 777 and ownership is root:root

I navigated to the location of those .pem files and verified contents exist (using cat) which, of course, in the process proved the path is correct.

Chased these down and verified contents exist (examples selected from a list of files I assume from various renewals):
-rw------- 1 root root 1704 Oct 15 03:57 0008_key-certbot.pem
-rw-r--r-- 1 root root 1293 Oct 15 03:57 0008_csr-certbot.pem

Up to a month or so ago, all worked well. (Application is an RSS feed reader, with the xml file generated by Enfeedia located in public accessible folder. I use Googles FeedBurner and it successfully access the xml file. Enfeedia includes feed reader application as part of its syndication functionality. Customer websites include a one line invocation of the feed reader functionality.

Linode personnel assure me no changes have been made to server software, and that they would not make any changes without my approval.

I've not been messing around with any code associated with the feed generation and syndication functionality.

I've not changed any paths to the various certs folders/files.

I've experiemented in my test cases with this line included and not included in php.ini:
openssl.cafile=/etc/letsencrypt/live/enfeedia.com/
Got error reports in both cases.

I came across this ...
phpthumb fopen(): SSL operation failed with code 1. OpenSSL Error messages - githubmemory
... during my testing and it fixed one test case (fopen) but I still have a problem with file_get_contents. I believe all it does is defeat checking certs, so I don't think it to be a wise solution, but I mention this in case it might help troubleshooting my problem:

I have solution for this Open filename phpthumb.functions.php at line 824 - 825 like show bellow ob_start(); if ($fp = fopen($url, 'rb') {

Change to like this ob_start(); $opts = array( "ssl" => array( "verify_peer" => false, "verify_peer_name" => false, ), ); if ($fp = fopen($url, 'rb', false, stream_context_create($opts))) {

I'm at a loss as to what to do next.

1 Like
#2

A couple things. First, openssl.cafile should point to a file - you have it pointing to a folder. Second, normally that would point to the system ca certificates store file.

You can find the folder for that with openssl version -d

Then look in that folder for something like ca-bundle.crt

But, do you even need to do that? I would think php's openssl would find the system ca store on its own. I don't know for sure - just wondering.

3 Likes
#3

Mike, thank you for your reply.

I tried point to a file in that enfeedia.com folder. Actually tried two files: cert.pem and privkey.pem. They redirect as follows:
cert.pem >> ../../archive/enfeedia.com/cert8.pem
privkey >> ../../archive/enfeedia.com/privkey.pem
Both failed.

(I deduce it's set up that way to facilitate changing keys doing renewals.)

I tried pointing to the system ca certificates store file (I don't know what that is) getting the folder as you advised. Failed.

I commented out that openssl.cafile line altogether, Failed, but with different warning:
include(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

Which is better, so to speak: Keep openssl.cafile line (and working on the file issue) or remove it (comment it out)?
openssl.cafile=/etc/letsencrypt/live/enfeedia.com/{file???}

1 Like
#4

I do not see anything wrong with your Let's Encrypt certificates for that site. And, this really isn't a php programming forum but I will give it one more go.

Your attempt at using cert.pem and privkey.pem for cafile is just wrong. cafile should be a composite file of trusted roots (or at least 1 root) which neither of these are.

Info like this is not at all helpful:

I tried pointing to the system ca certificates store file (I don't know what that is) getting the folder as you advised. Failed.

You should include the actual line you used and the error message to be helpful.

Still, I think you can leave the openssl.cafile (and openssl.capath) in php.ini commented out.

Does even a curl work on your system for that URL:

curl -I https://enfeedia.com/enfeedia.xml

What are the results of that curl? Show results in post.

4 Likes
#5

Why is there an "8" on the cert and not on the key file?

Also, the "fullchain8.pem" file should be used.
Better yet, their updated links kept in the /live/ folder should always work.

2 Likes
#6

It's my belief the 8 means from the 8th renewal, and in folder live, there's no number because it's the active file. But as you can tell from my posts here, I am a novice when it comes to certs.

#7

You should only reference files in the /live/ directory.

2 Likes
#8
  1. Typo on

cert.pem >> ../../archive/enfeedia.com/cert8.pem
privkey >> ../../archive/enfeedia.com/privkey.pem

Both privkey.pem is actually privkey8.pem.

  1. I don't know what this means and what I should change to make it happen. What file is a composite file you are referring to?

Your attempt at using cert.pem and privkey.pem for cafile is just wrong. cafile should be a composite file of trusted roots (or at least 1 root) which neither of these are.

  1. Regarding your comment...

A couple things. First, openssl.cafile should point to a file - you have it pointing to a folder. Second, normally that would point to the system ca certificates store file.
You can find the folder for that with openssl version -d
Then look in that folder for something like ca-bundle.crt

I found the folder to be /etc/pki/tls. I navigated there:

[ken@alpha tls]$ ls -l
total 24
lrwxrwxrwx 1 root root 49 Jul 27 2020 cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
drwxr-xr-x 2 root root 4096 Jul 27 2020 certs
drwxr-xr-x 2 root root 4096 Jul 27 2020 misc
-rw-r--r-- 1 root root 10923 Aug 6 2019 openssl.cnf
drwxr-xr-x 2 root root 4096 Aug 8 2019 private

Note, only the cert.pem was a symlink (terminology?) leads to something like a "bundle". No mention of a .crt file. So the actual line I tried was:

openssl.cafile=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

Go this failure:

Warning : fopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in /srv/www/enfeedia.com/public_html/test_fhandle.php on line 2

  1. Here' s what I get for curl -I https://enfeedia.com/enfeedia.xml:

HTTP/1.1 200 OK
Date: Sun, 28 Nov 2021 19:31:45 GMT
Server: Apache/2.4.6 (CentOS)
Last-Modified: Sat, 14 Nov 2020 14:37:18 GMT
ETag: "2cfd9-5b41215046c5e"
Accept-Ranges: bytes
Content-Length: 184281
Connection: close
Content-Type: text/xml

  1. You say, "I would think php's openssl would find the system ca store on its own". I don't know what the "system ca store" is. And if you're right, I should just
    comment out the openssl.cafile line in php.ini.

From here on, unless I say otherwise, or unless someone has something definitive about what that line I can trust should be, it will be commented out.

#9

I still don't think you need to set those in your php.ini at all.

I can do this in php right now without those set:

$url = 'https://www.enfeedia.com/enfeedia.xml';
$html = file_get_contents($url);
echo $html;

If that does not work for you then your CA Certificate store needs updating.

Most likely file_get_contents will work better than your fopen method anyway with a url as file name.

Update: I see our latest posts crossed. What does this show:

curl -I https://enfeedia.com/enfeedia.xml
3 Likes
#10

HTTP/1.1 200 OK
Date: Sun, 28 Nov 2021 19:40:37 GMT
Server: Apache/2.4.6 (CentOS)
Last-Modified: Sat, 14 Nov 2020 14:37:18 GMT
ETag: "2cfd9-5b41215046c5e"
Accept-Ranges: bytes
Content-Length: 184281
Connection: close
Content-Type: text/xml

I'll get back to you shortly about running that three line file_get_contents test.

1 Like
#11

Results of

$url = 'News from the Enfeedia.com News Feed Publishing Service';
$html = file_get_contents($url);
echo $html;

Three reports, where I discount the last two because the first one is fatal.

Warning : file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in /srv/www/enfeedia.com/public_html/test-file_get_contents.php on line 20

Warning : file_get_contents(): Failed to enable crypto in /srv/www/enfeedia.com/public_html/test-file_get_contents.php on line 20

Warning : file_get_contents(News from the Enfeedia.com News Feed Publishing Service): failed to open stream: operation failed in /srv/www/enfeedia.com/public_html/test-file_get_contents.php on line 20

1 Like
#12

Sounds like:

2 Likes
#13

If it's any help, Google's Feedburner has no trouble at all accessing the .xml feed file in Enfeedia and displaying it correctly. Here's one for my wife's website:

http://feeds.feedburner.com/enfeedia/usol

At a minimum, it adds credibility that Enfeedia does publish legit RSS feeds. Enfeedia's syndication feature is broken because, unlike Feedburner, Enfeedia can't see to open the xml feed files it publishes to the world.

1 Like
#14

OK, how do I do that? I did a forced renewal of the certs to hopefully get the "shop in order". My last renewal, about a month ago, was successful as was the forced renewal last week. Did > certbot renew --force-renewal

#15

There is no question the website is fine. At the beginning I said the certs were fine and you can use a curl to see it and I can use curl and php to see it.

The failure is in your php configuration. It would not hurt to update your CA root certificates. For Centos 7 it is:

sudo yum install -y ca-certificates

But, I do not think that will help your php problem. I have a feeling it relates to the openssl library built in to your version of php. I do not have a specific suggestion on how to remedy that right now though.

The first work-around that comes to mind is using the php built-in curl support rather than the implicit support for URLs in the file functions.

3 Likes
#16

Please don't use the force for that - LOL

3 Likes
#17

Desperation.

#18

What is your version of php?

2 Likes
#19

I'm terrified about installing ca-certificates. Seriously. I don't know what implications that has elsewhere. So, especially given your doubts about that helping, I will avoid that like the pandemic.

I also have no experience using curl. So that would be probably a steep learning curve for me including updating all my php code for file operations.

I keep wondering, what happened? This all worked so reliably, for over 10 years, during which I update my websites doing routine bug fixes and feature enhancements. But nothing related to SSL and keys and certs. I've been a happy camper just sticking to a schedule of doing renewals, with no hiccups as all. Smooth as silk.

My PHP package was updated back in 2020:
PHP 7.3.20 (cli) (built: Jul 7 2020 07:53:49) ( NTS )
Copyright (c) 1997-2018 The PHP Group

And if my recollection is correct, I was running 7.3 much earlier than that. As I said, I've not had the problems I'm experiencing now up until a month or so ago. I'd pull my hair out, but I'm already bald.

1 Like
#20

I wanna add two things:

Everything in getting onboard with SSL using Letsencrypt was done automatically. And thankfully, because it's a complicated topic.

I enormously appreciate the help I'm receiving here, the both of you spending your time on my problem.

3 Likes