Re: Renew expired certificate for Jenkins SAML plugin

[Ivan Fernandez Calvo]

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, 
david...@gmail.com 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  \
>   -keystore /path/to/saml-key.jks -storepass   \
>   -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: 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  
> 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, 
>> david...@gmail.com 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 kuisat...@gmail.com 
>>> 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 jenkinsci-use...@googlegroups.com.
>> To view this discussion on the web visit 
>> 

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  \
  -keystore /path/to/saml-key.jks -storepass   \
  -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: 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 
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,
> david...@gmail.com 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 kuisat...@gmail.com 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 jenkinsci-users+unsubscr...@googlegroups.com.
> 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 

Re: Renew expired certificate for Jenkins SAML plugin

[Ivan Fernandez Calvo]

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, david...@gmail.com 
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 kuisat...@gmail.com 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/8498a077-3cbf-4e02-ba08-85d66a4036een%40googlegroups.com.

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 kuisat...@gmail.com 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/250fc4c1-b044-4c07-a764-b45e35fe53d6n%40googlegroups.com.

Re: Renew expired certificate for Jenkins SAML plugin

[Ivan Fernandez Calvo]

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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/e5490d2b-bf6d-47f1-8ed4-513f7e59772dn%40googlegroups.com.

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?

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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAKjjcZ_ZCsG8ht%3DNB7zWbNF7PWDBheek9L%2BjObKxpsMRAx0jgQ%40mail.gmail.com.