There is an apache httpd server in the chroot. You update as you would update any other apache httpd server. Check `/etc/httpd` in Centos I believe...

Hi, Bryan. You can follow next steps to update Apache certificate (which indeed seems to be the cause of the issue here): 1. Move into container 2. Find out location of your default Java truststore (`cacerts` file): `# find / -ipath "*cacerts"` It may return several entries! The correct one will look similar to this: `/opt/jdk1.8.0_181/jre/lib/security/cacerts` 3. Backup all current Apache (httpd) certificates under `/etc/certs` and the `cacerts` file as well, to be able to roll-back to previous configuration easier; full vm back up is another option 4. Generate a new certificate for Apache and override `httpd.crt` with it. When generating, you may use the existing certificate as input, to produce CSR, example: `# openssl x509 -x509toreq -in /etc/certs/httpd.crt -out /etc/certs/httpd.csr -signkey /etc/certs/httpd.key`; keep everything stored under `/etc/certs/` 5. Delete the existing Apache certificate from `cacerts` to avoid ambiguity due to presense of 2 different certificates for the same entity after importing the new one: `# /opt/jdkx.x.x.x/jre/bin/keytool -delete -alias <hostname_of_your_gluu_server>_httpd /opt/jdkx.x.x.x/jre/lib/security/cacerts -storepass changeit` If this step fails, odds are you are using wrong `cacerts` file, there must be a certificate with such alias in the correct one and delete operation must succeed; you can view the contents of the store with `-list` command 6. Import the new signing certificate into the truststore: `# /opt/jdkx.x.x.x/jre/bin/keytool -importcert -file httpd.crt -keystore /opt/jdkx.x.x.x/jre/lib/security/cacerts -alias <hostname_of_your_gluu_server>_httpd -storepass changeit` 7. Make sure permissions won't prevent "apache" user from reading new items (setting ownership to "root:gluu" is enough) 9. Restart the container

Hello, thank you for the help. I followed your instructions except for step #6. Where I replaced `<hostname_of_your_gluu_server>_idp-signing` with `<hostname_of_your_gluu_server>_httpd` because that is the one we deleted in step #5. Should I have left it as you originally suggested? After completing the steps I got the same error. I think this is because the certs are self signed rather than signed by a trusted certificate authority. The "Let'sEncrypt" service is a trusted CA and has some automated cert signing tools like Certbot and I am now wondering if the Gluu team has experimented with this at all? Will this work with the Gluu certs? Also now when I look at the certs page in axtrust the httpd cert is no longer there.

Hi, Brian. > Where I replaced <hostname_of_your_gluu_server>_idp-signing with <hostname_of_your_gluu_server>_httpd because that is the one we deleted in step #5. Should I have left it as you originally suggested? No, your edit was corret, sorry for that one. >I think this is because the certs are self signed rather than signed by a trusted certificate authority. That's most likely the cause. As you seemed to be ready to use a proper certificate from the start, I just provided you instructions on how to install it. I.e. those steps assume you are using not a self-signed one. >The "Let'sEncrypt" service is a trusted CA and has some automated cert signing tools like Certbot and I am now wondering if the Gluu team has experimented with this at all? Some of our users employed it in the past, indeed. There shouldn't be much differences on how to approach it when it comes to Gluu Server, after all, not much specifics. If you just want to install certificate issued by them, move it inside container and run the commands above with it. If you need certificates to be auto-updated, following LetsEncrypt's guide on how to configure it should be enough.

Thanks again for your help. I got a CA signed cert and it looks like the gluu services accepted the cert and my web browser shows green https: however I am getting the same error from Chronograf. So I went through and changed the idp-signing and idp-encryption certs to my new cert and unfortunately that did not change anything either, do you have any suggestions on moving forward? One thing to note is that I only received .key and .crt files from my CA. What role does .csr pay? Since we are not uploading it to the key store I did not worry about it.

To clarify things: on step 4 you are either issuing a new self-signed cerficate, or create a CSR file which you then can upload to some CA and get a proper singed, universally trusted certificate from them. In your case I suppose you need to check LetsEncrypt docs about the proper procedures. >I went through and changed the idp-signing and idp-encryption certs to my new cert and unfortunately that did not change anything either Those have nothing to do with OIDC flows, they only matter if you use SAML flows. >One thing to note is that I only received .key and .crt files from my CA That's all you need. >What role does .csr pay? It's a certificate request usually needed to get a signed certificate from CA. Procedures may differ on per CA basis, though. We don't cover such specifics under community support. Let's put it this way: if when you try to access your Gluu Server's own pages you see in your browser that SSL/TLS connection is established using your updated certificate, then you succeeded with updating Apache's certificate, at least. If you still see "x509: certificate signed by unknown authority" error in your app, you may need to start investigating issue from its side, as I don't see what else could be wrong here, OIDC RPs don't deal with other certificates usually. We don't usually cover troubleshooting of products either than our own under Community support, unfortunately. You may need to ask in groups dedicated to your application instead. Apparently, it still doesn't trust your new certificate for some reason. You need to find out why.

thanks again