using own crt for ssl

[gitblit]

Originally reported on Google Code with ID 98

What steps will reproduce the problem?
1. type "keytool -import -alias hostname -file /path/to/cert.crt -storepass 123456"
2. go into gitblit.properties and change the server.storepassword to 123456
3. try to connect, and in chrome I instantly get a "Error 107 (net::ERR_SSL_PROTOCOL_ERROR):
SSL protocol error."

No other browsers can connect as well. Seems to have worked fine before I tried to
add my own keyfile, but really, this shoudn't be an issue.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
0.9.3

Please provide any additional information below.

Reported by kelly.elton@skylabsonline.com on 2012-05-17 19:06:56

[gitblit]

I've also tried adding -keyalg RSA and that didn't help either. I'm assume that there
is some string or something in gitblit that is used in opening the keyfile, but I don't
know.

Reported by kelly.elton@skylabsonline.com on 2012-05-17 19:08:05

[gitblit]

I've also switched to Debug mode, and ran gitblit so I could watch the output, and the
last line is 
INFO  Started SslSelectChannelConnector@0.0.0.0:9001 STARTING
The connections still fail, but nothing is printed to the console.

Reported by kelly.elton@skylabsonline.com on 2012-05-17 19:16:01

[gitblit]

Hi kelly.

Read the point "Creating your own Self-Signed Certificate" in http://gitblit.com/setup.html

Good luck

Reported by eguervos on 2012-05-17 20:21:05

[gitblit]

I've read that, and it works...problem is I'm trying to use a real certificate. I convert
it to a proper keyfile, but gitblit apparently can't handle it?

Reported by kelly.elton@skylabsonline.com on 2012-05-17 20:23:19

[gitblit]

1.- Review the contents of makekeystore_jdk.cmd
2.- Set your hostname into the HOSTNAME variable.
3.- Execute the script.

    This will generate a new certificate and keystore for your hostname protected by
- ->>>> server.storePassword. <<<<-

Reported by eguervos on 2012-05-18 09:46:23

[gitblit]

Hi Kelly, at the moment I do not have an answer for you.  However, I will be receiving
a wildcard certificate shortly so using a real cert on our corporate Gitblit install
will be a priority for me.  I'll report back whatever I learn during that process.

Reported by James.Moger on 2012-05-18 11:56:06

• Status changed: Accepted

[gitblit]

Thanks James.

Reported by kelly.elton@skylabsonline.com on 2012-05-18 17:18:18

[gitblit]

Hi Kelly,

I have reproduced your situation with my own wildcard certificate.  And then I found
a solution that worked for me.  Perhaps it will work for you too.

For better or worse our net admin went with GoDaddy - maybe because of Danica Patrick.
 :)  These instructions.... when followed _exactly_ ... work: http://support.godaddy.com/help/article/5239/generating-a-csr-and-installing-an-ssl-certificate-in-tomcat-4x5x6x

So if these instructions work, then how did I replicate your scenario?

Those instructions are divided into (1) generating the CSR (certificate request) and
(2) installing the certificate after one is issued.  As part of step 1 you create a
keystore from which to generate the CSR.  You MUST use this same keystore for step
2 - installing all certs.  If you do not use the same keystore (with, presumably, your
private key) you get precisely the same error message in Chrome.  No doubt, there are
probably 50 other ways to get this same error so maybe this will not help you.

And as stated in the Gitblit documentation, the store password and the cert passwords
must all match AND the keystore file must be named "keystore".

Good luck!

Reported by James.Moger on 2012-06-06 12:45:01

• Status changed: Done

[gitblit]

What steps will reproduce the problem?
I have followed the mentioned directions to generate and import a CA cert.  Here are
the following steps that I did and I cannot get my CA to work.  

1. Generate makekeystore_jdk.cmd 
2. Ran GoDaddy instructions step 4 to generate Cert Request (note not for wildcard
but for git.mydomain.com)
3. Received cert back from CA and followed GoDaddy instr. 1, 2 and 4 to add certs to
my keystore
4. Stop service and start Gitblit - The site proceeds to include the self-signed cert
as primary
5. I run a "keytool -delete" on the self-signed alias so that my CA cert is primary
6. Stop gitblit service start service and in chrome I get an SSL Error 107.  

Gitblit server.storePassword and the keystore pw is the same.  I'm running on https
443.  

What version of the product are you using? On what operating system?
1.1.0

Reported by cnlawrence1183 on 2012-12-03 20:30:23

[gitblit]

Sorry to clarify on step 4 gitblit is trying to use the self-signed cert even though
the CA cert is added to the keystore so in the next step I proceed to delete it.

Reported by cnlawrence1183 on 2012-12-03 20:32:23

[gitblit]

Hmmm.  Not sure.  My new favorite tool over the last few weeks has been Portecle.
http://portecle.sourceforge.net/webstart/portecle.jnlp
You might find it useful too.  You can visually inspect and manipulate JKS, P12, X509s,
etc.

Reported by James.Moger on 2012-12-03 20:55:12

[gitblit]

Okay so if I inspect the keystore with the selfsigned included there is a keypair. 
And when I import the cert there is just the cert not a corresponding pem.  How do
I create a keystore and generate a private key?  These are the steps that I did to
create the csr to getting the CA cert.

1. ran the jdk cmd file to generate selfsigned cert.  
2. Ran the Generate Request -genreq to get the csr
3. Uploaded the csr to namecheap.com 
4. Received crt file and Imported into keystore through -trustcacert
5. Listing shows the key pair for the self signed and just the X509 crt from my CA
6. If i leave it like this it will only use the self signed and not the one from the
CA
7. I do not seem to have a private key that is associated with the CA crt.  

Can anyone see what I'm missing?  

Reported by cnlawrence1183 on 2012-12-04 15:02:39

[gitblit]

(PEM is a format, like zip.  It may contain public certificates.  It may contain private
keys.  It may contain both.  Having a PEM file is not required - it is just a container.)

I'm not an X509 expert but I've spent a bunch of time on X509 recently so here is my
current understanding:

Summary:
When you import your CA-signed cert this must override your self-signed cert (i.e.
import using same alias).
You must also import each of the CA's certificates (however many there are).

Important Information:
When you say "CA cert" you have to be careful here because that means something else.
 In your usage "CA cert" sounds like it is referring to your cert that you generate
that the CA signed.  I make that distinction because the CA will have one or more certs
too which make up the trust chain for your CA-signed certificate.

You will never have the CA's private key.  If you did, then you could sign certs all
day long and charge $$ for them too.  :)  You already have your own private key - it
is in the keystore you generated in the first step.

Basic idea here:
1. you generate a private key and public self-signed certificate describing your server
using the hostname as the common name (CN).
2. you create a certificate signing request (CSR) from your public, self-signed certificate
and upload it to your CA.
3. your CA decides to trust you for a fee and signs your self-signed certificate making
it an authentic CA-signed certificate.
4. your CA returns your now CA-signed certificate along with one or more of the CA's
public certificates establishing the chain of trust from your public certificate back
to the CA's root certificate.
5. you import the CA's certificates
6. you import your CA-signed public certificate, using your original alias and overwriting
your self-signed certificate but preserving your private key

After you have done this you should have one or more CA public certs in your keystore,
your private key, and your public CA-signed certificate.  The original self-signed
public certificate should have been replaced.

*Really Important Information*:
Your private key is never transmitted as part of the CSR and you don't get a private
key back from the CA.  You have the only copy of your private key in your keystore.
 You can not serve SSL with just a public, CA-signed certificate.  You must also have
the corresponding private key that was used to create the public certificate.  Hopefully
you still have it.  If your private key was deleted when you did "keytool -delete",
then I'm afraid your CA-signed certificate can not be used for serving SSL.

http://www.sslshopper.com/what-is-a-csr-certificate-signing-request.html

Reported by James.Moger on 2012-12-04 16:13:57

[gitblit]

I also tried to use the portecle to Import CA Reply and I receive a "the public key
of ca reply does not match the public key of the key entry" even after I import the
AddTrustExternaCARoot.crt and the PositiveSSLCA2.crt to the keystore and also to the
global cacerts.  

I saw on http://docs.webhelpdesk.com/s/library/m/5197/l/54068-importing-an-ssl-certificate
some documentation that eluded to the issuer property being the same but how can they
when the CA will be diff from the self signed keypair.  

Reported by cnlawrence1183 on 2012-12-04 16:29:14

[gitblit]

The reason I needed the CA cert imported is because TeamCity would error out because
of not verified ssl when setting up a git CVS to run build tests.

I ended up completely abandoning getting the Gitblit CA Cert reply imported and went
to the TeamCity server browsed to the https site for my Giblit server exported the
cert to a local file.  Then I used portecle (very helpful to help understand keystores!
thx James) to import the selfsigned cert into the TeamCity's jre cacert.  Restarted
Web and Build agent services and it connected successfully.  

I tried to start over and recreate the keystore and generate the csr and did not delete
the original keypair and I got the error posted in Comment 14 when trying to import
the CA Reply.  I tried different ways of importing the chain to the local keystore
and then to the cacert but that did not resolve the import CA Reply issue.  I'm leaving
it alone until another day.  Thanks for your help and explanation on the x509 process.

Reported by cnlawrence1183 on 2012-12-04 16:57:21

[gitblit]

I have another tip that I just learned.  If your keystore has multiple private keys,
the private key/cert with the first string-sorted alias will be used by Gitblit when
serving.

e.g. if trust store looks like
alias
"localhost"
"192.168.1.65"

The private key and public cert for alias "192.168.1.65" will be used.  The common
name (CN) must still match the hostname of the url request in order for the browser/client
to not complain, but the first string-sorted cert will always be served by Jetty regardless
of availability of other certs with the proper CN.

This is a configurable option in Jetty and I will create a setting to specify the alias
to use for serving SSL.

Reported by James.Moger on 2012-12-05 15:10:32

• Status changed: Accepted
• Labels added: Milestone-1.2.0

[gitblit]

Alias specification is implemented on master.

Reported by James.Moger on 2012-12-06 00:41:48

• Status changed: Queued

[gitblit]

v1.2.0 has been deployed.

Reported by James.Moger on 2013-01-01 01:06:25

• Status changed: Fixed

[shadowfoxish]

Just wanted to leave a comment here since I was facing similar issues using a legitimate wildcard certificate to secure my GitBlit installation (1.8.0) with https. I think the biggest hurdles were generating the jks certificate file from the pfx file, ensuring the store password was the same and set in all the places (like the installservice.cmd file), and that the server.certificateAlias was set to something actually returned by keytool -list -v -keystore keystore.jks. The alias wasn't a hostname for me, it was actually a {GUID}. Also not running the service until these things were all done helped too.

[shadowfoxish]

Additional info, as I had to update certs when they expired and have some additional observations to share. When you install the PFX in the Windows cert manager and allow for export of the private key, you have the option to re-export it later and "Include all certificates in the certification path if possible". Make sure you do this. I used Portecle to create the new JKS file and imported my newly exported PFX which included the whole cert chain. Portecle can show you the certs embedded in the file and if you only have the one, then its no good. In my case, I had 3 certs. This was my flux certpacitor. I found I really didn't need to do anything with the serverTrustStore.jks file.