Also had this issue, matching the privateKey and keyStore solved it. 

On Monday, March 6, 2017 at 9:26:59 AM UTC-7, wrote:
> Thanks for the post steven, I had the same issue i.e. different password 
> for keystore and key. recreating the keystore and key with the same 
> resolved it.
> On Friday, December 19, 2014 at 2:05:59 PM UTC-5, Steven Erat wrote:
>> I encountered the same exception.  The short answer is that the 
>> privateKey password did not match the keyStore password, at first.   When I 
>> realized this could be a problem, I tried setting the JENKINS_ARG option 
>> —httpsPrivateKeyPassword to in addition to the --httpsKeyStorePassword, but 
>> I got a "Unrecognized option" from Winstone which didn't make sense.
>> Here's a snippet of correspondence when I was describing the situation to 
>> a colleague:
>> ---------
>> Looking at the Winstone class where the last exception came from: 
>> There was the following comment block:
>> // There are many legacy setups in which the KeyStore password and the
>> // key password are identical and people will not even be aware that these
>> // are two different things
>> // Therefore if no httpsPrivateKeyPassword is explicitely set we try to
>> // use the KeyStore password also for the key password not to break
>> // backward compatibility
>> // Otherwise the following code will completely break the startup of
>> // Jenkins in case the --httpsPrivateKeyPassword parameter is not set
>> privateKeyPassword = Option.HTTPS_PRIVATE_KEY_PASSWORD.get(args, 
>> keystorePassword);
>> Then I found the Winstone options class, which also showed that a 
>> ‘httpsPrivateKeyPassword’ option could be passed.  So I changed the 
>> /etc/sysconfig/jenkins to use this instead:
>> JENKINS_ARGS="--httpsPort=443 
>> --httpsKeyStore=/usr/lib/jenkins/certs/jenkins.jks  
>> --httpsKeyStorePassword=abc --httpsPrivateKeyPassword=xyz"
>> However, starting Jenkins still failed, but this time with 
>> “java.lang.IllegalArgumentException: Unrecognized option: 
>> —httpsPrivateKeyPassword”, and that doesn’t make sense at all.
>> I going try to recreate the jenkins.jks keystone that I’m using, but 
>> match the private key password that I used originally.    If they both have 
>> the same password, then I don’t have to pass in "—httpsPrivateKeyPassword” 
>> separately.
>> Ok,  recreating the jks file with the same password used for the private 
>> key password worked.  Jenkins would start and the SSL cert was verified in 
>> the browser. 

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 view this discussion on the web visit
For more options, visit

Reply via email to