I am unable to correctly configure Jenkins to use a StartSSL certificate.
I'm running it with command line arguments that specify paths to the private key and my certificate as shown on the Jenkins Wiki (at the bottom: https://wiki.jenkins-ci.org/display/JENKINS/Starting+and+Accessing+Jenkins).
I've obtained a private key and a certificate from StartSSL
I've placed them in a particular folder
I'm running Jenkins as follows: java -jar jenkins.war --httpPort=-1 --httpsPort=8080 --httpsCertificate=<mydomain.crt file> --httpsPrivateKey=<my private key file>
Jenkins starts successfully. Opening https://mydomain:8080/ in Firefox says that the connection is untrusted:
mydomain:8080 uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
I've tried verifying mydomain:8080 on various SSL checker websites:
OK mydomain resolves to xxx.xxx.xxx.xxx
OK The certificate was issued by StartCom.
OK The certificate will expire in XXX days.
OK The hostname (mydomain) is correctly listed in the certificate.
Not OK The certificate is not trusted in all web browsers.
You may need to install an Intermediate/chain certificate
to link it to a trusted root certificate.
StartSSL does not have explicit instructions for setting up Jenkins. I've tried following up on similar tutorials for other kinds of servers, and copied the intermediate authority files from StartCom into a unified certificate (ca.pem and sub.class1.server.ca.pem as noted here: http://www.startssl.com/?app=42).
However, this did not change anything.
SSL checkers like www.sslshopper.com/ssl-checker.html still report that the website is untrusted.
Also, the GitHub image caching service is not rendering the build status icon from Jenkins for the same reason.
How do I add the issuer chain correctly to my certificate?
I had a similar problem and after some research what got everything to be trusted was :
Merged the intermediate authority certificate and <mydomain.crt file> into 1 unified certificate called merged.cer using the link you mentioned
(From: https://serverfault.com/questions/569866/jenkins-wont-serve-with-ca-signed-certificate)
openssl pkcs12 -inkey /location/to/key.pem -in /location/to/merged.cer -export -out keys.pkcs12
keytool -importkeystore -srckeystore keys.pkcs12 -srcstoretype pkcs12 -destkeystore jenkins.jks
NOTE: the key to use for the merged.cer should be the same as <my private key file>
Then follow the Jenkins Wiki to use the KeyStore instead of the certificate
java -jar jenkins.war --httpPort=-1 --httpsPort=8080 --httpsKeyStore=/path/to/jenkins.jks --httpsPrivateKey=<my private key file>
Related
I am with little knowledge of certificates.
Need add certificate for jetty (v.9.4.11) which is a part of application.
Try with self-signed - all OK. But now, need do it with organization official certificate.
Administrator gives me 2 files - .cer and .p7b. Documentation of application said that enough command like:
keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore keystore.jks
I will try this command with .cer instead .crt. Keystore was created, configured jetty-http.xml and started application. Try open - and error SSL_ERROR_NO_CIPHER_OVERLAP.
Check with openssl connect to my address with -tsl1/1_1/1_2 - nothing, connection ok, but but nothing in keystore.
Check with keytool content of keystore - 1 entry, trustedCertEntry and no key (not private/not public)
Is it real to configure only with this 2 files - .cer/.p7b or i need something else?
Usually when setting up SSL Certificates, you will more often than not have 2 or 3 files.
The base working format for certificates is a certificate / key pair.
For example, you could have a certificate for example.com with it's associated key.
example.com.cer
example.com.key
If the certificates were created using a provider, you will most likely also need the Root Certificate Authority. In our infra for instance, our ROOT CA's are in the .pem or .cer format. Here is a config for one of my webservers, using the entrust.crt as the root ca chain file :
SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
SSLCertificateChainFile /etc/apache2/ssl/entrust.crt
In your case, you have a .p7b file. P7B files often have more than a single entry, they can contain both the certificate and the ROOT CA's chains. You can open the p7b in a windows machine, then find the certificates and right-click > Export. Export your files in Base64 and set them on your server.
The problem was that beginner .csr-file was incorrect.
-Recreated it
get .cer
run in cmd: certutil -repairstore my "serial" for generate key
export to .pfx
-connect apllication to .pfx
I am trying to configure Jenkins on Windows with a SLL certificate following these instructions. Instead of using a Digicert certificate, our IT administrator would like to generate a certificate using the Windows AD CS using the certificate snap-in of mmc.
However we cannot figure out how to import the keytool generated csr certificate request into the certificate snap-in.
If I use a certificate with a recreated certificate request in the mmc certificate store, the certificate is rejected with the following message:
keytool -importcert -alias jenkins -file "D:\Temp\jenkins\jenkins.pem" -keystore "D:\Temp\jenkins\jenkins.jks"
Enter keystore password:
keytool error: java.lang.Exception: Certificate reply does not contain public key for <jenkins>
Does anyone know how to create an SSL certificate from the Windows certificate store based on a java keytool created csr certificate request?
I was able to get Jenkins running with SSL and this is what I did.
On the Jenkins Master
In the Certificate Snap-in of mmc, navigate to Certificates (Local
Computer) / Personal.
Right click Personal Folder and select All Tasks / Request New
Certificate...
Confirm the next two Enrollment pages by clicking on Next.
Check a Webserver Active Directory Enrollment Policy.
A Warning Message shows below the Enrollment Policy
More information is required to enroll for this certificate. Click here
to configure settings.
Click on it.
Fill out the Certificate Properties: Subject name: Common name:
[the name of your jenkins server] Alternative name: DNS: [the
name of your jenkins server] Alternative name: DNS: [the full
name of your jenkins server including your domain]Confirm the
page with OK and the following two pages.
Export the Certificate as PFX format Right click on
certificate All Tasks / Export...
Check: Yes, export the private key Check Include all
certificates in the certification path if possible Check:
Export all extended properties Since we are exporting the
private key, we must provide a password Check: Password and
enter your password and password confirmation
Pick a path for your PFX certificate and finish the export.
Export the certificate one more time without a password in the
Base-64 encoded X.509 (.CER) format.
Rename the resulting .CER file into .PEM.
Create a java key store on the Jenkins server with
keytool -genkeypair -keysize 2048 -keyalg RSA -alias jenkins -keystore jenkins.jks
Answer the questions appropriate for your company and organisation.
Import the PFX certificate into the java keystore with
keytool -importkeystore -srckeystore jenkins.pfx -srcstoretype pkcs12 -destkeystore jenkins.jks -deststoretype JKS
Copy the jenkins.jks to secrets directory where Jenkins is
installed (in my case C:\Program Files (x86)\Jenkins\secrets).
Add the certificate to the Jenkins startup parameters:
-Djavax.net.ssl.trustStore=%JENKINS_HOME%\secrets\jenkins.jks
-Djavax.net.ssl.trustStorePassword=[your password for the java key store]
Restart the jenkins service
On the Jenkins Agent
Import the PEM certificate from above into the java keystore from the command line with administrator priviliges:
keytool -import -alias jenkins -keystore "C:\Program Files (x86)\Java\jre1.8.0_161\lib\security\cacerts" -file [your pem file]
Enter the password of the keystore (by
default changeit) Trust this certificate? [no]: yes
Make sure your jenkins-slave.xml in %JENKINS_HOME% does not contain
-noCheckCertificate in the arguments.
Restart the service jenkinsslave-D__Jenkins.
I am reading the tutorial you have mentioned in your post. And I see this sentence:
"if making your own certificate skip steps 3, 4, and 5". Your code seems to be the specified in step 5.
You could try to copy the keystore file to your Jenkins secrets directory as mentioned in step 6.
This link can also be helpful.
I got a certificate from Geotrust and I'm trying to apply it to my Tomcat web server, as can be seen in the image below, I left .csr and .p7b in the same directory (java / bin)
the softlayer support team, has indicated the link https://www.digicert.com/ssl-certificate-installation-tomcat.htm as help and when I execute the command I get the error:keytool error: java.lang.Exception: Input not an X.509 certificate
Anyone have been through this and can you help me? I've been trying to figure it out for days.
Reasons for the error :-
You are importing the certificate (p7b) in a wrong keystore . when you import the certificate in an existing keystore it will never ask you to punch in the password twice. If its asking you to punch in the password twice, it means its creating a new keystore. In a new keystore, you cannot import the the certificates as private entry You can only create Trusted Entry and add the certificates as trusted.
Solution
1)If you have the private key with you, please create a text file and rename the file as example.pem with all the certificates and private key in it in the below sequence
a) private key
b) Server certificate
c) Intermediate Certificate
d) Root Certificate.
2) Run the below openssl command
openssl pkcs12 -in example.pem -out certificate.pfx
3) As you have the pfx file from the above command, use the keytool command below to convert this in jks format for tomcat
keytool -importkeystore -srckeystore certificate.pfx -srcstoretype
pkcs12 -destkeystore certificate.jks -deststoretype jks.
4) Provide the certificate.jks directive in server.xml file of tomcat along with its password
5) Restart the tomcat service.
Hope this helps ..
I am trying to secure my eXist-db app, which means the only port I want to leave open should be 8443 (for using WebDAV and admin app). This is the basic secure port eXist-db have open since the installation. It uses self-signed certificate. I have no problem with replacing default certificate with a new one but the problem is I am not able to do that with CA signed certificate.
I tried:
sudo rm eXist-db/tools/jetty/etc/keystore
cat ServerCertificate.crt Alpiro-TrustProvider-IntermediateCA.crt Root.cer > cert-chain.txt
I cleaned bad ends of lines and verified every certificate starts on a new line.
openssl pkcs12 -export -inkey my-app.key -in cert-chain.txt -out my-app.pkcs12
keytool -importkeystore -srckeystore my-app.pkcs12 -srcstoretype PKCS12 -destkeystore eXist-db/tools/jetty/etc/keystore
After restart, I checked the connection with: openssl s_client -connect xx.xx.xxx.xxx:8443 and everything seems fine. I can see there is my trusted certificate and the connection (handshake) simply works. However, browsers still claim it is not a trusted connection.
When I try to check something over https via XQuery, it throws:
java.security.cert.CertificateException: No subject alternative names matching IP address xx.xx.xxx.xxx found …
The solution is quite trivial. The problem was I had been trying to access the site via IP, not via fully qualified domain name. Certificates are associated with domain names, not IPs!
I have requested a class 1 certificate from StartSSL and installed it in Weblogic 10.0.1 (see screenshots).
The browsers (Chrome & IE9 on Windows 7, IE8 on XPSP3) still give a certificate error (see screenshots).
I think the StartSSL root certificate is available in several browsers (see here). Please advise.
StartSSL Class 1 certificates are signed by a intermediate CA, which is signed by the StartCom Root CA. For your browser to trust this certificate, it needs to know the trust chain up to the Root CA it already knows.
Your server needs to send the complete trust chain to the browser (minus the Root CA), so your browser can verify that your certificate is trusted.
See the StartSSL FAQ for more info.
Found the problem. I've imported the StartSSL certificate incorrectly in our keystore. Also, I've specified "weblogic" as alias in the Weblogic console which is not the certificate but the public/private key pair. I'm using Portecle to edit the keystore.
When I've noticed that I was probably using the wrong alias I've changed it to the alias of the certificate. This resulted in a Weblogic error:
Inconsistent security configuration, weblogic.management.configuration.ConfigurationException: No identity key/certificate entry was found under alias startssl-hostname in keystore keystore_StartSSL on server servername
In the end I've followed these steps to pack the certificate and private key in one PKCS#12 keystore. I've then imported that keystore into our java keystore using Portecle:
Export the "weblogic" public/private key using Portecle as a PKCS#12 keystore.
Extract the private key from this keystore using openssl:
openssl pkcs12 -in weblogic.p12 -nocerts -out privatekey.pem
Package the certificate and private key as a PKCS#12 keystore (cert.p12) using openssl:
openssl pkcs12 -export -in cert.cer -inkey privatekey.pem -out cert.p12 -name cert -CAfile ca.pem -caname root
Import cert.p12 file into our java keystore using Portecle using "cert" as alias.
Changed the Weblogic configuration to use the "cert" alias with the correct passphrase.
And it worked!
PS: I've added the JCE unlimited strength policy along the way since Portecle complained about this at one point.
Generally the trust store and keystore would be separate, but it will not cause the error above.
If your browser does not trust the CA then you will receive the above error. You need to add the root CA to your browser. You can check the certs that your browser supports.
Eg for IE -> Tools -> Internet Options -> Content -> Certificates -> Trusted Root CA
Assuming you need to import this into one or two browsers, its not a big deal. But if you need to do this across the enterprise (meaning 100 or 1000 of browsers), you will need help from your desktop support team !