the result is the same you have a private key and a certificate that you have to import in the Keystore, This Keystore is the one you have to configure in the SAML plugin
El domingo, 8 de noviembre de 2020 a las 20:26:50 UTC+1, [email protected] escribió: > Thank you for reply. > > If we are using encryption, does it means that typically when starting > with Jenkins SAML setup (e.g. ADFS) we are first creating certificate and > keypair via keytool (which will be stored in saml-jenkins-keystore.jks) and > then uploading it to ADFS, or are we first starting from ADFS side and > configuring metadata/keys/certificates on that side and uploading those to > Jenkins afterwards ? > > Thanks again. > > On Tuesday, November 3, 2020 at 5:17:35 PM UTC [email protected] wrote: > >> This Keystore is automatically created if you do not configure >> encryption, the Pac4j needs a key to work even though you do not use >> encryption. So in general if you do not use sign or encryption in the SAML >> messages (not related to TLS) you do need to configure anything this file >> will be used only to make the library work, but your IdP will not request >> your certificate. If you use encryption, you should configure your own >> Keystore and manage the keys in there. >> >> In the Documentation of the plugin you can found how to configure >> encryption and how this Keystore works. >> >> https://github.com/jenkinsci/saml-plugin/blob/master/doc/CONFIGURE.md >> >> *Encryption* - If your provider requires encryption or signing, you can >> specify the keystore details here that should be used. If you do not >> specify a keystore, the plugin would create one with a key that is valid >> for a year, this key would be recreate when it expires, by default the key >> is not exposed in the SP metadata if you do not enable signing. >> >> - *Keystore path* - The path to the keystore file created with the >> keygen command. >> - *Key Alias* - The alias used in the -alias argument of the keytool< >> command. >> - *Keystore password* - The password used in the -storepass argument >> of the keytool command. >> - *Private Key password* - The password used in the -keypass argument >> of keytool. >> - *Auth Request Signature* - Enable signature of the Redirect Binding >> Auth Request, If you enable it the encryption and signing key would >> available in the SP metadata file and URL >> (JENKINS_URL/securityRealm/metadata). The disable of signing auth request >> does not work with HTTP redirection binging, it only works for POST >> binding. >> >> >> El martes, 3 de noviembre de 2020 a las 16:48:28 UTC+1, Igor David >> escribió: >> >>> Hello, >>> >>> What is the correct way to renew an expired certificate >>> (JENKINS_HOME/saml-jenkins-keystore.jks) which is used for SAML Plugin >>> please? >>> >>> https://github.com/jenkinsci/saml-plugin >>> >>> In that process, what is the purpose of saml-jenkins-keystore.xml (e.g. >>> is it generated every time a new certificate is renewed or)? >>> >>> I have tried removing JENKINS_HOME/saml-jenkins-keystore.jk, disabling >>> SAML plugin and re-enabling it again and I do see that it has generated new >>> certificate, but I am not sure if this is the correct way and what happens >>> with JENKINS_HOME/saml-jenkins-keystore.xml in that case? >>> >>> Thanks in advance. >>> >>> Kind regards, >>> Igor >>> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8498a077-3cbf-4e02-ba08-85d66a4036een%40googlegroups.com.
