Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use system truststore #68

Closed
fvanderbiest opened this issue Nov 30, 2018 · 7 comments
Closed

Use system truststore #68

fvanderbiest opened this issue Nov 30, 2018 · 7 comments

Comments

@fvanderbiest
Copy link
Member

Pierre recommends using the system wide truststore instead of using a custom one for every tomcat.

This means:

  • getting the certificate from openssl s_client -connect localhost:443
  • inserting it into /usr/local/share/ca-certificates/georchestra.crt
  • running update-ca-certificates
  • removing tomcat options javax.net.ssl.trustStore*
landryb added a commit that referenced this issue Mar 4, 2020
we need to overwrite the jks-keystore hook to add detection for adoptopenjdk

- point adoptopenjdk at the generated truststore
- stop messing with keytool to generate a java truststore with a useless localhost cert
- stop pointing jvms at a local java truststore

tested with vagrant on buster/debian 10
@landryb
Copy link
Member

landryb commented Mar 4, 2020

should work now, tests welcome ;)

@landryb landryb closed this as completed Mar 4, 2020
@spelhate
Copy link
Member

spelhate commented Apr 8, 2021

Salut,
Avec cette nouvelle configuration, je suppose qu'il faut également retirer ou bien adapter ces lignes :

keystoreFile="/etc/tomcat9/keystore"
keystorePass="{{ tomcat_keystore_pass }}"

@landryb
Copy link
Member

landryb commented Apr 8, 2021

et bien ... je ne sais plus :/ ou alors pointer vers le keystore par defaut ?

@landryb
Copy link
Member

landryb commented Apr 21, 2021

une instance de test qui marchait hier n'arrive plus a valider de tickets CAS ajd, et si dans le server.xml de proxycas je pointe keystoreFile vers /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/jre/lib/security/cacerts (le keystore par défaut, dans lequel notre certificat autosigné à été importé) c'est pareil.

java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:443)
	org.jasig.cas.client.validation.AbstractCasProtocolUrlBasedTicketValidator.retrieveResponseFromServer(AbstractCasProtocolUrlBasedTicketValidator.java:41)
	org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java:193)

@landryb
Copy link
Member

landryb commented Apr 21, 2021

j'ai pu retrouver un CAS fonctionnel en commentant toute la section liée au connector écoutant sur le port 8443, mais je ne sais plus dans quels cas ce dernier était nécessaire..;

@landryb
Copy link
Member

landryb commented May 19, 2021

et ce meme CAS qui fonctionnait (avec le connector sur le port 8443 commenté) n'arrive soudainement plus a valider de tickets via SSL, sans raison apparente. Décidément, java et ssl..

@landryb
Copy link
Member

landryb commented May 19, 2021

hm, donc avec update-ca-certificates on dirait que le cert autosigné se retrouve dans /etc/ssl/certs/java/cacerts et pas/plus dans /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/jre/lib/security/cacerts.. le playbook ansible s'assure pourtant que ce dernier est un lien vers le premier, donc une maj d'un autre composant a du casser ce lien. Ca remarche une fois replayé le tag keystore..

landryb added a commit that referenced this issue Aug 2, 2021
…orgotten in #68

not even sure this is still needed, but what we have now cant be right
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants