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.

writer:
  label: Veröffentlicher
  type: select
  required: true
  options: api
  api: 
    url: "{{ site.url() }}/teammembers.json"
    fetch: teammembers
    text: "{{ item.name.value }}"
    value: "{{ item.name.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:
https://www.sslshopper.com/ssl-checker.html

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?

Nope

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

Which Kirby version do you use?

3.5.7.1

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
============
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAwTzELMAkGA1UE
BhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2VhcmNoIEdyb3VwMRUwEwYDVQQD
EwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQG
EwJVUzEpMCcGA1UEChMgSW50ZXJuZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMT
DElTUkcgUm9vdCBYMTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54r
Vygch77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+0TM8ukj1
3Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6UA5/TR5d8mUgjU+g4rk8K
b4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sWT8KOEUt+zwvo/7V3LvSye0rgTBIlDHCN
Aymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyHB5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ
4Q7e2RCOFvu396j3x+UCB5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf
1b0SHzUvKBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWnOlFu
hjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTnjh8BCNAw1FtxNrQH
usEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbwqHyGO0aoSCqI3Haadr8faqU9GY/r
OPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CIrU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4G
A1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY
9umbbjANBgkqhkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL
ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ3BebYhtF8GaV
0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KKNFtY2PwByVS5uCbMiogziUwt
hDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJw
TdwJx4nLCgdNbOhdjsnvzqvHu7UrTkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nx
e5AW0wdeRlN8NwdCjNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZA
JzVcoyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq4RgqsahD
YVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPAmRGunUHBcnWEvgJBQl9n
JEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57demyPxgcYxn/eR44/KJ4EBs+lVDR3veyJ
m+kXQ99b21/+jh5Xos1AnX5iItreGCc=
-----END CERTIFICATE-----

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.