WordPress – Plugin WP CONTENT CRAWL – cURL error 60: SSL certificate problem: unable to get local issuer certificate

This is most likely related to the expired DST Root CA X3, which expired Sep 30 14:01:15 2021 GMT.

Libcurl is using VERIFYPEER and VERIFYHOST to ensure trust between client and server.

The DST CA Root X3 certificate is part of the "cacert-bundle".
As of today the "cacert-bundle" can be found here: https://curl.se/docs/caextract.html
as part of the bundle https://curl.se/ca/cacert.pem.

The expired certificate is:

Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Validity
    Not Before: Sep 30 21:12:19 2000 GMT
    Not After : Sep 30 14:01:15 2021 GMT
    Subject: O=Digital Signature Trust Co., CN=DST Root CA X3
    Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    Public-Key: (2048 bit)

Which is used to verify peer in libcurl calls to websites using Let’s Encrypt issued certificates.

Here’s a detailed solution to your problem: https://stackoverflow.com/a/69411107/1549092

Another solutions is to disable VERIFYHOST and VERIFYPEER in your curl calls using that WP code.

Before doing that there’s something to be aware of:

Let’s explain the comparing your SSL/TLS certificate to the verified CA Authorities and how does that affect Man-in-the-middle (MITM) attacks.

Your program could be misled into talking to another server instead. This can be achieved through several mechanisms like DNS or ARP poisoning.
The intruder can also self-sign a certificate with the same ‘comon name’ your program is expecting.
The communication would still be encrypted but you would be giving away your secrets to an impostor.
This kind of attack is called ‘man-in-the-middle’.

Defeating the ‘man-in-the-middle’
We need to verify the certificate being presented to us is good for real. We do this by comparing it against a certificate we reasonably trust.
If the remote resource is protected by a certificate issued by one of the main CA’s like Verisign, GeoTrust etc., you can safely compare against Mozilla’s CA certificate bundle, which you can get from http://curl.haxx.se/docs/caextract.html

CURLOPT_SSL_VERIFYHOST and CURLOPT_SSL_VERIFYPEER prevent MITM attacks

WARNING: Disabling this would prevent CURL from detecting Man-in-the-middle’ attacks!

@param CURLOPT_SSL_VERIFYPEER

Check the existence of a common name in the SSL peer certificate.
Check the existence of a common name and also verify that it matches the hostname provided.

To disable set the value to false:

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

@param CURLOPT_SSL_VERIFYHOST

FALSE to stop CURL from verifying the peer’s certificate.
Alternate certificates to verify against can be specified with the CURLOPT_CAINFO option or a certificate directory can be specified with the CURLOPT_CAPATH option.
CURLOPT_SSL_VERIFYHOST may also need to be TRUE or FALSE if CURLOPT_SSL_VERIFYPEER is disabled (it defaults to 2).
Setting CURLOPT_SSL_VERIFYHOST to 2 (This is the default value) will guarantee that the certificate being presented to you have a ‘common name’ matching the URN you are using to access the remote resource.
This is a healthy check but it doesn’t guarantee your program is not being decieved.

To disable this set the value to false:

curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);

Doing this disables the most important part of the CURL SSL handshake for your website!

I would consider resolving this issue globally for your OS as explained here: https://stackoverflow.com/a/69411107/1549092