https://gluu.org/docs/admin-guide/certificate/

Hello, thank you for your quick reply. I re-installed the server and rand the Letsencrypt procedure in the Gluu environment and I got now a secure connection to the server. However when I logon I get now following error: Something wrong happened. Login failed, oxTrust wasn't allow to access user data Return to the application using below button. Did I miss anything ?

Did you re-run setup? Or you re-installed the package? Not sure why this was necessary unless you changed the hostname. Please attach the oxTrust, oxAuth, Apache2, and installation log (in `/install/community-edition-setup`).

Hi, Bart. The guide you are referencing was written for 2.4.4 packages, I'm not sure it's been already tested for Gluu CE 3.0 Let me do a quick test, could you please share a link to some paper you were using to generate "Lets encrypt" certificate before, so I could try to correctly reproduce your issue?

Hi, Here is what I did. - Installed Gluu on VM server Cent OS 7 with recommended specs (2 core - 4GB memory) - Setup server' hostname to <my_hostname> and fixed dns to redirect to server IP - Followed the standard installation - Enabled the chroot - Logged in and ran the setup.py > linked to <my_hostname> enabled all options, changed the default password - Installed EPEL packages required for Letsencryp certbot tool: yum install epel-release - Installed Certbot : yum install certbot - Stopped httpd, ldap & jetty services - Ran certbot and selected create cert only for <my_hostname>-> this will spin a temp http server on port 443, which is now available because httpd is down - Certbot installes the certificates in /etc/letsencrypt/live/<my_hostname> - Took backup of certificates and cacerts - Copied certificates cp privkey1.pem /etc/certs/httpd.key and cp privkey1.pem /etc/certs/httpd.key - Followed the manual as described , only changed the owner and file permissions of the .der file after running the openssl command : chmod 555 httpd.der and chown root:gluu httpd.der - Created the cacert file with the keytool. As I did not know the repository password created a new one upon prompt - Started the services back up ldap -> httpd -> Jetty Gluu initially came up and I got a valid https connection with the Letsencrypt certificate. After login I got to the error message. I then stopped and stared the services individually again , the chroot environment and even did a complete server reboot. In all occasions Jetty/java took a lot of CPU and failed to start. I ended up removing all and deleting the VM. Thank you for looking into this. Let me know if you could reproduce and/or need extra info

Apache didn't change from 2.4.4 --> 3.0.0 ... but we'll check it.

I just did this on my end. You need to "delete" the certificate entry using keytool and then insert the new one. Without that step some stuff breaks. The JKS file on 3.0.0 is "inside" the JRE. The password for it is "changeit" which is the default for all JREs. If you don't do this, nothing will work... Here are the cli commands in the chroot/jail: ``` /opt/jdk1.8.0_112/bin/keytool -delete -alias <your_fqdn>_httpd -keystore /opt/jdk1.8.0_112/jre/lib/security/cacerts /opt/jdk1.8.0_112/bin/keytool -importcert -file /etc/certs/httpd.der -keystore /opt/jdk1.8.0_112/jre/lib/security/cacerts -alias <your_fqdn>_httpd ``` Also, don't use certbot, it adds all sorts of unnecessary stuff... Use getacme.sh -> https://github.com/Neilpang/acme.sh

Hi, Patrick. Thanks for the detailed steps. > You need to "delete" the certificate entry using keytool and then insert the new one. Without that step some stuff breaks. Yes, you are right, it's mandatory steps. At least, you must import the new one to the default java certificate storage, but it's also recommended to remove the old one too, it was reported leaving it there may cause issues. Thanks again for sharing results of your research, we'll update docs accordingly.

updated the document with the changes and added delete step, to make sure that there is no error while updating documents.

Hi, Nicolas. No, we don't have a script for that. Still, it's not that much complex procedure, and usually you won't need to conduct it too often when administering your own instance.

I try using acme.sh and use the following command for retrieving the cert. acme.sh --issue -d my-host.my-domain.com -w /var/www/html Responses from the execution states that the cert. has been issued successfully, and a number of files are found created under the folder ~/.acme.sh/my-host.my-domain.com. However, according to the web site of acme.sh, the created files cannot be used directly. And, indeed, the created cert. files are having extension "cer" but not "crt". Following the instruction of the web site of acme.sh, I run the following command. acme.sh --install-cert -d my-host.my-domain.com However, no file is found changed in the folder /etc/certs/. Can any one help?

> And, indeed, the created cert. files are having extension "cer" but not "crt". Extensions are not that important, but rather the actual format used to store certificate in this file. You can find a lot of good materials over Internet on this subject, like [this one](https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how-to-convert-them). Regardless of which of 2 ways to encode it was used, you can re-encode it to the other one easily. I'm still not quite sure what your issue is. We have a good detailed guide containing all the steps [here](https://gluu.org/docs/ce/2.4.4/operation/update-certificate/). Just note that `cacerts` store will be at different location in CE 3.0.x. You could use something like `# find / -ipath "*cacerts*"` inside container to find out where it's located.

Thanks for the reply from Aliaksandr.