SSL certificate problem: certificate has expired

I have run into a problem, that when using the select field in the blueprints with the option:api turned on, this error in the panel is thrown: SSL certificate problem: certificate has expired.

Im not sure why this is happening, since the Lets Encrypt SSL certificate which is installed on the domain is a valid certificate and is working perfectly fine in the backend aswell as the frontend, only when it comes to this field I run into problems.

  label: Veröffentlicher
  type: select
  required: true
  options: api
    url: "{{ site.url() }}/teammembers.json"
    fetch: teammembers
    text: "{{ }}"
    value: "{{ }}, {{ item.image.value }}"

If you have given permission from your browser when you first entered the site, it will not give a continuous SSL error.

You can check your SSL status with SSL checking tools:

I dont really understand what you mean with “if you have given permission”, when i open my website in any browser I dont need to give any permissions, the ssl certificate is a valid one.

The Status of the certificate, even to the tool its all good.

Do you see any different error output in console?


When checking the panel with the debug option the error only extends to this:

Which Kirby version do you use?

Pinging @lukasbestle who have better knowledge about this.

This could be a problem with the expired root certificate from Lets Encrypt.

In the directory ./kirby is the cacert.pem - maybe it is enough to remove the certificate “DST Root CA X3” there, which is the expired one.

1 Like

Oh, yes. Absolutely. I also thought about this when reading the issue description.

We will update the CA list with the next release. Until then, removing the expired CA root cert in kirby/cacert.pem should do the trick.

As @fizzoc and @lukasbestle suggested I deleted DST Root CA X3 from there aswell as ISRG Root X1, sadly it didnt do the trick, how can I find out what cert has to be deleted from the list?

My installed cert on the website is a Lets Encrypt cert.
The Path of the certificate shows that it was issued by ISRG Root X1/R3.

Don’t delete the ISRG Root X1 - that’s the new root of Lets Encrypt.

If you didn’t backup:

ISRG Root X1

Alright, but even after restoring my backup with all the certs in the list, and only removing DST Root CA X3 the problem still persists.

I’ve tried all kind of variants now of editing the .pem file, from removing all but the applying certs to doing the exact reverse, and only deleting DST Root CA, and other tries.

My Kirby folder is used by two seperate intances with different ssl certs, in every case my alternative domain works flawlessly. But no matter which certs are deleted from the list, I cannot get my main domain to run with the lets encrypt certificate.

The expiry of the old DST Root CA X3 certificate has caused a lot of pain all around the web. The OpenSSL team (the developers of the library that’s also used by cURL to handle the TLS connection, where cURL is the library Kirby uses to request the data from the remote options API) has written a detailed blog post about this topic.

TL;DR: If your PHP installation on your server is compiled with OpenSSL 1.0.2 or older, the library will always prefer the expired CA certificate. On OpenSSL 1.1.0 you shouldn’t have this problem at all, so I believe you have version 1.0.2.

The question is just why removing the expired cert from the CA bundle doesn’t fix the problem. According to the blog post it should. So maybe your OpenSSL uses the system CA bundle even though Kirby tells it to use ours?

What you could do to verify this is to run:

curl https://yourdomain.example/your/teammembers.json

on the command line on the server. If that works even with the exact URL that fails inside Kirby, then your server is probably fine and we need to keep searching. If it doesn’t work, then you may need to delete the same CA cert from the system CA bundle first.

PS: Kirby 3.6.0-beta.3 (and of course the final 3.6.0 release) will ship without the expired CA certificate.