• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Error ca-bundle.crt on Almalinux 9

OverWolf

Regular Pleskian
Server operating system version
Almalinux 9
Plesk version and microupdate number
18.0.52u3
Hi,
I have some big problem with extension after a reboot of my server.
Now I cannot see any extension on catalog (Internal server error Retry) and either my extensions because I cannot access this management.

In panel.log I have this error :


Code:
 ERR [extension/sslit] Failed to load ssl config data: Could not get Mozilla tls config: cURL error 77: error setting certificate file: /etc/pki/tls/certs/ca-bundle.crt (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
 ERR [panel] Could not get Mozilla tls config: cURL error 77: error setting certificate file: /etc/pki/tls/certs/ca-bundle.crt (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
 ERR [extension/catalog] error setting certificate file: /etc/pki/tls/certs/ca-bundle.crt

I have read some other post, and this error came out if your OS is old. But I'm on Almalinux 9 and this is my problem.

So what I can do to resolve this error ?
 
Hi,

some other info about this problem :

Code:
Starting Berkeley Internet Name Domain (DNS)...
Service 'named' was not restarted because Plesk uses 'named' in chroot environment.
If you want to restart the 'named' service, please use 'service named-chroot restart'.
named.service: Control process exited, code=exited, status=1/FAILURE
named.service: Failed with result 'exit-code'.
Failed to start Berkeley Internet Name Domain (DNS).
 
Hi,
I think that the problem is somewhere over php.it (panel.ini) of plesk, because if I try to make this test I have no error


Code:
curl -v https://google.com
*   Trying 142.250.184.110:443...
* Connected to google.com (142.250.184.110) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.google.com
*  start date: May 22 08:17:22 2023 GMT
*  expire date: Aug 14 08:17:21 2023 GMT
*  subjectAltName: host "google.com" matched cert's "google.com"
*  issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* Using Stream ID: 1 (easy handle 0x55f6b540cf10)
* TLSv1.2 (OUT), TLS header, Unknown (23):
> GET / HTTP/2
> Host: google.com
> user-agent: curl/7.76.1
> accept: */*
>
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.2 (IN), TLS header, Unknown (23):
< HTTP/2 301
< location: https://www.google.com/
< content-type: text/html; charset=UTF-8
< content-security-policy-report-only: object-src 'none';base-uri 'self';script-src 'nonce-oORKgUf2JEoca6f4UHcD2Q' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
< date: Sun, 18 Jun 2023 11:11:58 GMT
< expires: Sun, 18 Jun 2023 11:11:58 GMT
< cache-control: private, max-age=2592000
< server: gws
< content-length: 220
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< set-cookie: CONSENT=PENDING+243; expires=Tue, 17-Jun-2025 11:11:58 GMT; path=/; domain=.google.com; Secure
< p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
<
* TLSv1.2 (IN), TLS header, Unknown (23):
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
* Connection #0 to host google.com left intact
 
Hi Maarten,

I don't know why named was failed, but now it's working :
Code:
 named-chroot.service - Berkeley Internet Name Domain (DNS)
     Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/named-chroot.service.d
             └─respawn.conf
     Active: active (running) since Sun 2023-06-18 13:39:00 CEST; 2h 41min ago
    Process: 817 ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z /etc/named.conf (code=exited, status=0/SUCCESS)
    Process: 874 ExecStart=/usr/sbin/named -u named -t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 882 (named)
      Tasks: 8 (limit: 50586)
     Memory: 50.3M
        CPU: 404ms
     CGroup: /system.slice/named-chroot.service
             └─882 /usr/sbin/named -u named -t /var/named/chroot -c /etc/named.conf -u named -n 2

Jun 18 14:39:00 xxx.server.net named[882]: network unreachable resolving './DNSKEY/IN': 2001:503:ba3e::2:30#53
 
Curl 77 indicates a problem with reading the SSL CA certificate.

Can you check if the certificate exists and has the correct file permissions?
Code:
# ls -l /etc/pki/tls/certs/ca-bundle.crt
lrwxrwxrwx. 1 root root 49 Sep 13  2022 /etc/pki/tls/certs/ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# ls -l /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
-r--r--r--. 1 root root 214712 Jan 14 13:07 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
 
Please also try this:

1) Remove cache files
2) Create Plesk database backup
3) Remove cache records from Plesk database
4) Restart Plesk service

like

Code:
# rm -rf /usr/local/psa/var/cache/https*
# plesk db dump > /root/psa_dump.sql
# plesk db "delete from PersistentCache where events like '%catalog%'"
# service sw-engine restart
 
Curl 77 indicates a problem with reading the SSL CA certificate.

Can you check if the certificate exists and has the correct file permissions?
yes, they have correct permission
Code:
ls -l /etc/pki/tls/certs/ca-bundle.crt
lrwxrwxrwx. 1 root root 49 Sep 21  2022 /etc/pki/tls/certs/ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

ls -l /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
-r--r--r-- 1 root root 214712 Jun 18 13:36 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
The only different from your is the "." (final) for .pem
 
Please also try this:

1) Remove cache files
2) Create Plesk database backup
3) Remove cache records from Plesk database
4) Restart Plesk service

like

Code:
# rm -rf /usr/local/psa/var/cache/https*
# plesk db dump > /root/psa_dump.sql
# plesk db "delete from PersistentCache where events like '%catalog%'"
# service sw-engine restart
I'll try this, but I've seen that I haven't any https* file in cache and in psa db seems that PersistenCache isn't present (fast search).
Is this normal ?
 
Back
Top