Renew expired certificate for Jenkins SAML plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Renew expired certificate for Jenkins SAML plugin

Igor David
Hello,

What is the correct way to renew an expired certificate (JENKINS_HOME/saml-jenkins-keystore.jks) which is used for SAML Plugin please?


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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAKjjcZ_ZCsG8ht%3DNB7zWbNF7PWDBheek9L%2BjObKxpsMRAx0jgQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Renew expired certificate for Jenkins SAML plugin

kuisathaverat
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?


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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e5490d2b-bf6d-47f1-8ed4-513f7e59772dn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Renew expired certificate for Jenkins SAML plugin

Igor David
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 [hidden email] 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.


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?


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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/250fc4c1-b044-4c07-a764-b45e35fe53d6n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Renew expired certificate for Jenkins SAML plugin

kuisathaverat
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, [hidden email] 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 [hidden email] 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.


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?


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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8498a077-3cbf-4e02-ba08-85d66a4036een%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Renew expired certificate for Jenkins SAML plugin

Igor David
Thanks all for the replies.

I have generated a new JKS via the following command (had different values):

$JAVA_HOME/bin/keytool -genkeypair -alias saml-key -keypass <pw1> \
  -keystore /path/to/saml-key.jks -storepass  <pw2> \
  -keyalg RSA -keysize 2048 -validity 3650
I then pointed in Jenkins UI to the newly created JKS keystore, which it identified correctly.

I then selected "Auth Request Signature" and clicked on the following link in Jenkins Security configuration:

image.png
This has generated a new XML file which has a new X509 certificate in it, and I believe this should be used with an AD provider.

Would this be a correct procedure?

Thanks again.

Kind regards,
Igor

On Sun, Nov 8, 2020 at 7:48 PM Ivan Fernandez Calvo <[hidden email]> wrote:
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, [hidden email] 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 [hidden email] 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.


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?


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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8498a077-3cbf-4e02-ba08-85d66a4036een%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAKjjcZ_rhEbg3Dg7uGWHHz2ftuX8j1%3DoDoK6efvL3wHy-cMcig%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Renew expired certificate for Jenkins SAML plugin

kuisathaverat
Yes, it is correct, you have to import the certificate you see in the JENKINS_HOME/saml-sp-metadata.xml file(or in the URL you marked in the screenshot) in your IdP

El viernes, 13 de noviembre de 2020 a las 21:05:07 UTC+1, [hidden email] escribió:
Thanks all for the replies.

I have generated a new JKS via the following command (had different values):

$JAVA_HOME/bin/keytool -genkeypair -alias saml-key -keypass <pw1> \
  -keystore /path/to/saml-key.jks -storepass  <pw2> \
  -keyalg RSA -keysize 2048 -validity 3650
I then pointed in Jenkins UI to the newly created JKS keystore, which it identified correctly.

I then selected "Auth Request Signature" and clicked on the following link in Jenkins Security configuration:

image.png
This has generated a new XML file which has a new X509 certificate in it, and I believe this should be used with an AD provider.

Would this be a correct procedure?

Thanks again.

Kind regards,
Igor

On Sun, Nov 8, 2020 at 7:48 PM Ivan Fernandez Calvo <[hidden email]> wrote:
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, [hidden email] 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 [hidden email] 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.


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?


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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8498a077-3cbf-4e02-ba08-85d66a4036een%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/fd826b2a-94a0-494a-9a27-b582dd5cb44fn%40googlegroups.com.