Hi Kevin Fletcher, Thank you for reaching out gluu support, i will asist you on this ticket. please allow me some time to pull out right information for you. thanks and regards Mohit Mali

Hi Kevin Fletcher, I hope you are follow the right documentation link. https://gluu.org/docs/ce/3.1.6/admin-guide/certificate/ may i know the full arguments you are passing to generate the certificate 1. wget https://ox.gluu.org/maven/org/xdi/oxauth-client/3.1.6.sp1/oxauth-client-3.1.6.sp1-jar-with-dependencies.jar -O oxauth-client.jar 2. java -jar oxauth-client.jar <arguments> Thanks and regards Mohit Mali

I figured that we needed to regenerate the certificates. First question. Do I need to be in the chroot to download and run the oxauth-client.jar, or can I just run it from outside chroot and point to the /opt/gluu-*/etc/certs/ folder. Second I do not know the correct sequence of options to run to renew the certificate. Some of the things I have tried are: java -jar oxauth-client.jar -expiration 365 -keystore ./idp/idp-signing.key -sig_keys RS256 -dnname login.test.flvc.org java -jar oxauth-client.jar -expiration 365 -keystore ./idp/idp-signing.key -sig_keys RS256 ...and other combinations. It would be nice if the documentation had examples of how to renew the certificates.

Hi, Kevin. By IDP's signing and encryption keys, which ones do you mean? Is it about oxAuth keys (OpenID Connect), or about Shibboleth IDP's keys (SAML)?

Judging by your last post, it seems it's about IDP's keys - then you are using a wrong procedure.

This problem is affecting our external customers. Please escalate this ticket. We would like to resolve this problem this morning. Rick

Hi, Rick. Could you please confirm what "encryption keys" do you need to renew? Is it Shibboleth IDP's or oxAuth's keys?

Ok, got it - it seems like it's indeed IDP's keys. I'm not sure then why `oxauth-client.jar` got involved at all. I'll provide you steps you need soon.

Hi, Rick and Kevin. Here are the steps (please note they assume you still have your original keys under `/etc/certs/` intact; if you changed it while using the wrong steps mentioned before, you'll need to re-create the keys first): 1. Create backups of your current IDP certs: `# mkdir /etc/certs/backup_certs; cp /etc/certs/idp-* /etc/certs/backup_certs/` 2. Create new CSRs: - `# openssl req -new -key /etc/certs/idp-signing.key -out /etc/certs/idp-signing.csr -subj '/CN=login.test.flvc.org/O=Florida Virtual Campus/C=US/ST=FL/L=Pensacola'` - `# openssl req -new -key /etc/certs/idp-encryption.key -out /etc/certs/idp-encryption.csr -subj '/CN=login.test.flvc.org/O=Florida Virtual Campus/C=US/ST=FL/L=Pensacola'` 3. Issue new certs: - `# openssl x509 -req -days 3650 -in /etc/certs/idp-signing.csr -signkey /etc/certs/idp-signing.key -out /etc/certs/idp-signing.crt` - `# openssl x509 -req -days 3650 -in /etc/certs/idp-encryption.csr -signkey /etc/certs/idp-encryption.key -out /etc/certs/idp-encryption.crt` 4. Get aliases for current cerficates in truststore (you'll need them at next step): `# keytool -list -v -keystore /opt/amazon-corretto-8.222.10.1-linux-x64/jre/lib/security/cacerts -storepass changeit | grep _idp` 5. Remove the old `idp-signing` certificate and add the new one (if my guess of aliases used in your instance was wrong, use the correct ones you discovered on the previous step): - `# keytool -delete -alias login.test.flvc.org_idp-signing -keystore /opt/amazon-corretto-8.222.10.1-linux-x64/jre/lib/security/cacerts -storepass changeit` - `# keytool -import --trustcacerts -alias login.test.flvc.org_idp-signing -file /etc/certs/idp-signing.crt -keystore /opt/amazon-corretto-8.222.10.1-linux-x64/jre/lib/security/cacerts -storepass changeit` 6. Repeat the commands on previous step for `login.test.flvc.org_idp-encryption` alias and cert 7. Restart "idp" service Hope this will resolve it.

Could you please explain to me what the purpose of steps 8 - 11 provide. It looks like it just removes the aliases from the Truststore and recreates them. If we are using OpenSSL tool to regenerate the certificate and not the Java KeyGenerator, why do we need to perform these steps? I would just like to understand the process better.

Hi, Kevin. There were only 7 (numbered) steps. Perhaps some markdown issue, somewhere? But if I got you right, you were meaning actions like this: `# keytool -delete -alias login.test.flvc.org_idp-signing -keystore /opt/amazon-corretto-8.222.10.1-linux-x64/jre/lib/security/cacerts -storepass changeit` Deleteion is done just to prevent any possible ambiguities (like, several trust store entries related to the same service/hostname); to keap it clean and tidy. The main part here is addition of the newly generated certificate, to make Java trust it. That's just to prevent any issues due to the fact those certificates are self-signed - and sometimes such certificates can be rejected by Java, depending on when/where it encounteres it.