OpenLDAP's slapd simply does not send the certificate chain to clients when TLS handshaking, even if a bundle of server certificate, intermediate certificate has been provided to it as its certificate.
The only suitable work-around without turning certificate validation off on the clients is the following.
create a certificate bundle from intermediate ...
The snapshot I was given to use didn't contain the certificates after all. When I created a new instance based on yesterday's backup it worked fine. I'm not sure where the LetsEncrypt certs are stored for a Lightsail Bitnami WordPresss Multisite, but I sure can't find them!
as reference after researching incase someone looking for a self-signed certificate.
creating the key with the following command (Consider Password for Protection)
#openssl genrsa -aes128 -out fd.key 2048
Creating Certificate Signing Requests (CSR)
#openssl req -new -key fd.key -out fd.csr
place the extension information in a separate text file. I’m ...
Bitnami Engineer here
Do the SSL certificates (made with The Bitnami HTTPS Configuration Tool) only work on the original instance, even if the new instance are an exact copy? I'm guessing they do.
Yes, the SSL configuration is also copied to the new instance as you created a snapshot from the first instance. You can confirm this by checking the SSL ...
Thank you @bjoster. You stimulated some brain cell that caused me to analyze these "identical" servers. Somehow [::]:443 only existed on the server throwing errors.
netsh http delete sslcert ipport=[::]:443 Thank you for your time and inspiration!
It's been a while since I've been using Let's Encrypt certificates with OpenLDAP, but for me it wasn't necessary to create a file containing a chain. I only have this from my certbot renew-hook script:
cp /etc/letsencrypt/live/$domain/* /etc/ldap/ssl/
chown -R openldap:openldap /etc/ldap/ssl/
chmod 640 /etc/ldap/ssl/*
/etc/init.d/slapd force-reload >/dev/...
This (usually) means, that the endpoint 0.0.0.0:443 on this server uses a certificate that does not (or no longer) exist.
The easiest way to verify this is to go to the IIS Manager and look whether port 443 is still bound to the 'old' SSL certificate.
Or you can do this ("As Administrator") with
netsh http show sslcert
In the output, search for ...
I got it working now.
I had 3 approaches and this question was the result of my thirth approach.
Finally I imported the root certificate as IOS profile but I forgot to give trust to it. To do so, I needed to got to settings-> General -> info -> Certificate trust settings (last one) and there I had to enable my root certificate.
@user1686 suggested another solution in https://superuser.com/questions/1599666/view-all-certs-in-a-pem-cert-file-full-cert-chain-with-openssl-or-another-comm
it is part of the GnuTLS stack.
certtool -i < multiplecerts.pem
I can`t comment so I add a separate answer.
I tried to create a self-signed certificate for NGINX and it was easy, but when I wanted to add it to Chrome white list I had a problem. And my solution was to create a Root certificate and signed a child certificate by it.
So step by step.
Create file config_ssl_ca.cnf
Notice, config file has an option ...
I found this article of FreeCodeCamp and they posted the solution.
You have to use an ALIAS record (can be combined with CNAME record).
ALIAS at DNSimple and namecheap
ANAME at DNS Made Easy
ANAME at easyDNS
CNAME (virtual) at CloudFlare
Some providers don't have any of these option (e.g. United Domains) and you may have to transfer to another provider.