You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Brian Burch <br...@pingtoo.com> on 2012/10/26 11:11:22 UTC
SSL BIO/NIO setup with openssl CA puzzle
My production tomcat 7.0.26 (and its predecessors back as far as tc 5)
have been running with its original SSL server certificate in a JKS
keystore for many years.
I decided to retire my ancient java-based Certificate Authority and
create a new CA using openssl 1.0.1 under ubuntu linux.
I followed the guidance in
http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File
I thought it would be sensible to generate all my new certificates and
keystores using only openssl, so that I could use the same procedures
for java and non-java applications. This meant I needed to produce a
PKCS12 keystore for tomcat to use.
I hit a succession of problems and resolved them, so I thought it would
be helpful to update the wiki once I had a keystore that worked properly
(details of tips and gotchas available).
There are a lot of variables that I've explored, but I haven't yet
succeeded with my "pure openssl" approach. I do have a PKCS12 keystore
that keytool (with the -storetype pkcs12 option) can list perfectly, but
tomcat cannot open (with keystoreType="pkcs12" in the Connector). Both
tomcat, and keytool are running from java-6-sun-1.6.0.26/jre/lib/i386.
The log shows:
17-Oct-2012 15:33:51 org.apache.coyote.AbstractProtocol init
SEVERE: Failed to initialize end point associated with ProtocolHandler
["http-bio-443"]
java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
at
sun.security.util.DerInputStream.getLength(DerInputStream.java:544)
To understand the problem better, I started again by using keytool
-genkeypair and then -certreq. I issued the new certificate with openssl
and then imported the certificate chain into the JKS keystore.
At this point I don't actually have a problem, because both keytool and
tomcat are satisfied with the new keystore and my production system has
been converted successfully.
I hit some problems with this second approach (keytool genkepair), and
so I could add a few notes to the wiki entry. However, I'm bothered that
I couldn't get the first approach to work (pure openssl with pkcs12).
google throws up a lot of matches for the DerInputStream.getLength error
- even one from Mark Thomas about tomcat 4! I found a lot of red
herrings, and a few useful ideas, but nothing to resolve my problem.
It isn't encouraging to see "man pkcs12" ending with the sentence "Some
would argue that the PKCS#12 standard is one big bug :-)", and yet JKS
has to be a dead-end approach because it only applies to java.
I have another system with java-7-openjdk-i386, but I haven't yet done
any work on it. This openjdk does not ship with a keytool program, and
so I presume it will use openssl.
I wonder whether I have hit a sun java 6 (and 7?) bug that is of limited
interest - does anyone have any thoughts?
Thanks..
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 10/26/12 12:15 PM, Pid wrote:
> On 26/10/2012 13:53, Martin Gainty wrote:
>>
>> Hi Dan
>>
>> if you reference this simple test.jsp does every version of every
>> browser accept the cert as CA cert and properly installs your
>> certificate?
>>
>> <%@ page contentType="text/html"%> <html> <head> <!-- wait 1
>> second then download and install cert --> <meta
>> http-equiv="refresh" content="1;
>> URL=http://DanMachine:8080/Danwebapp/DanCertificate.cer">
>> </head> <body> </body> </html>
>>
>> Martin Gainty ______________________________________________ Jogi
>> és Bizalmassági kinyilatkoztatás/Verzicht und
>> Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez
>> az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor
>> kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása
>> vagy másolatának készítése nem megengedett. Ez az üzenet csak
>> ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs.
>> Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért
>> minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt.
>
>
> That's a classic, surely? Anyone? No?
MG non-sequitur FTW!
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCK2ccACgkQ9CaO5/Lv0PCVqQCgj6gdAN9pbm1H1tUldVNNPfsa
WLIAnjsz2YyHrogY5fEZ3SpkI8gihySM
=5QCK
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
Posted by Pid <pi...@pidster.com>.
On 26/10/2012 13:53, Martin Gainty wrote:
>
> Hi Dan
>
> if you reference this simple test.jsp does every version of every browser accept the cert as CA cert and properly installs your certificate?
>
> <%@ page contentType="text/html"%>
> <html>
> <head>
> <!-- wait 1 second then download and install cert -->
> <meta http-equiv="refresh" content="1; URL=http://DanMachine:8080/Danwebapp/DanCertificate.cer">
> </head>
> <body>
> </body>
> </html>
>
> Martin Gainty
> ______________________________________________
> Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
> Ez az
> üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
> jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
> készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
> semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
> könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
> ezen üzenet tartalma miatt.
That's a classic, surely? Anyone? No?
p
--
[key:62590808]
RE: SSL BIO/NIO setup with openssl CA puzzle
Posted by Martin Gainty <mg...@hotmail.com>.
Hi Dan
if you reference this simple test.jsp does every version of every browser accept the cert as CA cert and properly installs your certificate?
<%@ page contentType="text/html"%>
<html>
<head>
<!-- wait 1 second then download and install cert -->
<meta http-equiv="refresh" content="1; URL=http://DanMachine:8080/Danwebapp/DanCertificate.cer">
</head>
<body>
</body>
</html>
Martin Gainty
______________________________________________
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Subject: Re: SSL BIO/NIO setup with openssl CA puzzle
> From: dmikusa@vmware.com
> Date: Fri, 26 Oct 2012 08:24:44 -0400
> To: users@tomcat.apache.org
>
> On Oct 26, 2012, at 5:11 AM, Brian Burch wrote:
>
> > My production tomcat 7.0.26 (and its predecessors back as far as tc 5) have been running with its original SSL server certificate in a JKS keystore for many years.
> >
> > I decided to retire my ancient java-based Certificate Authority and create a new CA using openssl 1.0.1 under ubuntu linux.
>
> Just my $0.02, but if you are just using Java based applications, stick with keytool. It will save you time.
>
> >
> > I followed the guidance in http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File
> >
> > I thought it would be sensible to generate all my new certificates and keystores using only openssl, so that I could use the same procedures for java and non-java applications. This meant I needed to produce a PKCS12 keystore for tomcat to use.
> >
> > I hit a succession of problems and resolved them, so I thought it would be helpful to update the wiki once I had a keystore that worked properly (details of tips and gotchas available).
> >
> > There are a lot of variables that I've explored, but I haven't yet succeeded with my "pure openssl" approach.
>
> I believe that what you are trying to do should work. It might be easier to debug if we could see a list of the commands that you've run. Maybe just copy and paste your shell session?
>
> > I do have a PKCS12 keystore that keytool (with the -storetype pkcs12 option) can list perfectly, but tomcat cannot open (with keystoreType="pkcs12" in the Connector). Both tomcat, and keytool are running from java-6-sun-1.6.0.26/jre/lib/i386. The log shows:
> >
> > 17-Oct-2012 15:33:51 org.apache.coyote.AbstractProtocol init
> > SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"]
> > java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
> > at sun.security.util.DerInputStream.getLength(DerInputStream.java:544)
>
> Please include your connector configuration.
>
> Dan
>
>
> >
> >
> > To understand the problem better, I started again by using keytool -genkeypair and then -certreq. I issued the new certificate with openssl and then imported the certificate chain into the JKS keystore.
> >
> > At this point I don't actually have a problem, because both keytool and tomcat are satisfied with the new keystore and my production system has been converted successfully.
> >
> > I hit some problems with this second approach (keytool genkepair), and so I could add a few notes to the wiki entry. However, I'm bothered that I couldn't get the first approach to work (pure openssl with pkcs12).
> >
> > google throws up a lot of matches for the DerInputStream.getLength error - even one from Mark Thomas about tomcat 4! I found a lot of red herrings, and a few useful ideas, but nothing to resolve my problem.
> >
> > It isn't encouraging to see "man pkcs12" ending with the sentence "Some would argue that the PKCS#12 standard is one big bug :-)", and yet JKS has to be a dead-end approach because it only applies to java.
> >
> > I have another system with java-7-openjdk-i386, but I haven't yet done any work on it. This openjdk does not ship with a keytool program, and so I presume it will use openssl.
> >
> > I wonder whether I have hit a sun java 6 (and 7?) bug that is of limited interest - does anyone have any thoughts?
> >
> > Thanks..
> >
> > Brian
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: SSL BIO/NIO setup with openssl CA puzzle
Posted by Brian Burch <br...@pingtoo.com>.
On 31/10/12 16:39, Daniel Mikusa wrote:
> On Oct 31, 2012, at 10:23 AM, Brian Burch wrote:
>
>> On 26/10/12 13:24, Daniel Mikusa wrote:
>>> On Oct 26, 2012, at 5:11 AM, Brian Burch wrote:
<snip/>
>> 2.8. keytool -list -v -keystore jks-keystore shows the keystore contents as two entries:
>> 2.8.1. the first has an alias of tomcat, a private key entry and the two certificates which comprise the complete chain.
>> 2.8.2. the second has an alias of "Certificate Authority", with only the CA's certificate.
>>
>> Observation 2.8.2 indicates that I have put too much into this certificate store and that step 2.6 was redundant. Nevertheless, tomcat is perfectly happy to start its SSL Connector using this keystore.
>
>
> Have you tried deleting the second alias? Does it continue to work without this alias?
>
> Also, it might be interesting to convert this working JKS keystore into a PKCS12 keystore and see if it continues to work with Tomcat. I think you can do that with a command like this…
>
> keytool -importkeystore -srckeystore jks-keystore -srcstoretype jks -srcstorepass changeit -srcalias tomcat -destkeystore pkcs12-keystore -deststoretype pkcs12 -deststorepass changeit
I just copied the "fat" keystore to a new file and verified it was
identical. Then I ran:
keytool -delete -keystore jks-keystore -alias "Certificate Authority"
I printed the contents of keystore to confirm a) the tomcat collection
of private key and certificate chain were still present, and b) the
second alias had gone.
Tomcat started successfully using this new "minimal" keystore, so we can
conclude that my step 2.6 was definitely not necessary. This is because
the openssl certificate authority (by default) had bundled the entire
authority chain into the new server certificate.
I'll try your other suggestions later, but I thought it would be helpful
to clear up this particular issue quickly.
Regards,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
Posted by Daniel Mikusa <dm...@vmware.com>.
On Oct 31, 2012, at 10:23 AM, Brian Burch wrote:
> On 26/10/12 13:24, Daniel Mikusa wrote:
>> On Oct 26, 2012, at 5:11 AM, Brian Burch wrote:
>>
>>> My production tomcat 7.0.26 (and its predecessors back as far as tc 5) have been running with its original SSL server certificate in a JKS keystore for many years.
>>>
>>> I decided to retire my ancient java-based Certificate Authority and create a new CA using openssl 1.0.1 under ubuntu linux.
>>
>> Just my $0.02, but if you are just using Java based applications, stick with keytool. It will save you time.
>
> Well, yes, that was true for me too Dan (see case 2 below). But the tomcat wiki describes how to support pkcs12 and it ought to work (or say under what circumstances it will not).
>
>>> I followed the guidance in http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File
>>>
>>> I thought it would be sensible to generate all my new certificates and keystores using only openssl, so that I could use the same procedures for java and non-java applications. This meant I needed to produce a PKCS12 keystore for tomcat to use.
>>>
>>> I hit a succession of problems and resolved them, so I thought it would be helpful to update the wiki once I had a keystore that worked properly (details of tips and gotchas available).
>>>
>>> There are a lot of variables that I've explored, but I haven't yet succeeded with my "pure openssl" approach.
>>
>> I believe that what you are trying to do should work. It might be easier to debug if we could see a list of the commands that you've run. Maybe just copy and paste your shell session?
>
> Thanks for your interest, Dan. I've gone through all the steps in my notes carefully, and done my best to confirm these results.
>
> 1. Verify the openssl self-signed CA certificate (rsa 2048 bit key)
>
> 1.1. openssl x509 -noout -text cacert.pem displays OK.
>
> 1.2. strip all lines before "-----BEGIN CERTIFICATE-----" and after "-----END CERTIFICATE-----"
>
> 1.3. keytool -printcert -file cacert-bare.pem displays the self-signed certificate and extensions.
>
> ------------------------
>
> 2. create a JKS keystore and issue a cert with the openssl CA
>
> 2.1. keytool -genkeypair -alias tomcat -keyalg RSA -keysize 1024 -keystore jks-keystore -validity 2000 -dname "CN=www.mydomain.com,OU=servers,O=mydomain.com"
> .. using the same passphrase for the private key and the keystore.
>
> 2.2. keytool -list -v -keystore jks-keystore displays the RSA key wrapped with a self-signed certificate.
>
> 2.3. keytool -certreq -keystore jks-keystore -file jks-req -alias tomcat
>
> 2.4. issue the new certificate from the openssl CA, AND THEN strip everything from the file outside the delimiters.
>
> 2.5. keytool -printcert -file jks-servercert-bare.pem displays the ca-signed certificate and extensions.
>
> 2.6. keytool -importcert -keystore jks-keystore -file cacert-bare.pem -alias "Certificate Authority"
>
> 2.7. keytool -importcert -keystore jks-keystore -file jks-servercert-bare.pem -alias "tomcat"
>
> 2.8. keytool -list -v -keystore jks-keystore shows the keystore contents as two entries:
> 2.8.1. the first has an alias of tomcat, a private key entry and the two certificates which comprise the complete chain.
> 2.8.2. the second has an alias of "Certificate Authority", with only the CA's certificate.
>
> Observation 2.8.2 indicates that I have put too much into this certificate store and that step 2.6 was redundant. Nevertheless, tomcat is perfectly happy to start its SSL Connector using this keystore.
Have you tried deleting the second alias? Does it continue to work without this alias?
Also, it might be interesting to convert this working JKS keystore into a PKCS12 keystore and see if it continues to work with Tomcat. I think you can do that with a command like this…
keytool -importkeystore -srckeystore jks-keystore -srcstoretype jks -srcstorepass changeit -srcalias tomcat -destkeystore pkcs12-keystore -deststoretype pkcs12 -deststorepass changeit
> ------------------------
>
> 3. create a PKCS12 keystore and issue a cert with the openssl CA
>
> 3.1. CA.pl -newreq, with appropriate parameter values for the DN of the server and an RSA 1024 bit key pair. This command creates newkey.pem and newreq.pem files, both without any text before or after the delimiter lines.
>
> 3.2. openssl rsa -noout -text -in newkey.pem opens and prints the contents of the key pair.
>
> 3.3. openssl req -noout -text -in newreq.pem opens and prints the contents of the certificate request, including the server's new public key.
>
> 3.4. CA.pl -sign, issues the server certificate. It is prefixed with a text representation of the contents.
>
> 3.5. Strip everything outside the delimiters from the newcert.pem file.
>
> 3.6. openssl x509 -noout -text -in newcert-bare.pem opens and prints the contents of the certificate, including the server's public key.
>
> 3.7. openssl pkcs12 -export -in newcert-bare.pem -inkey newkey.pem -name "tomcat" -chain -CAfile cacert-bare.pem -caname "Certificate Authority" -out keystore-pkcs12 (using the same password for the keystore as the key).
>
> 3.8. openssl pkcs12 -noout -info -in keystore-pkcs12 -- displays the kinds of things in the binary file, i.e.
>
> MAC Iteration 2048
> MAC verified OK
> PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
> Certificate bag
> Certificate bag
> PKCS7 Data
> Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
>
> 3.9. keytool -list -keystore keystore-pkcs12 -storetype pkcs12 -- displays the kinds of things in the binary file, i.e.
>
> Keystore type: PKCS12
> Keystore provider: SunJSSE
>
> Your keystore contains 1 entry
>
> tomcat, 30-Oct-2012, PrivateKeyEntry,
> Certificate fingerprint (MD5): 80:4A:98:FD:73:DB:9B:E0:EE:3D:C6:82:75:7A:95:DE
>
> However, tomcat fails to start its SSL Connector using this keystore with the log messages below:
Again, it might be interesting to see if you convert the PKCS12 keystore to a JKS keystore if Tomcat works OK. I think this command should accomplish that.
keytool -importkeystore -srckeystore keystore-pkcs12 -srcstoretype pkcs12 -srcstorepass changeit -srcalias tomcat -destkeystore keystore-jks -deststoretype jks -deststorepass changeit
>
>>> I do have a PKCS12 keystore that keytool (with the -storetype pkcs12 option) can list perfectly, but tomcat cannot open (with keystoreType="pkcs12" in the Connector). Both tomcat, and keytool are running from java-6-sun-1.6.0.26/jre/lib/i386. The log shows:
>>>
>>> 17-Oct-2012 15:33:51 org.apache.coyote.AbstractProtocol init
>>> SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"]
>>> java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
>>> at sun.security.util.DerInputStream.getLength(DerInputStream.java:544)
>>
>> Please include your connector configuration.
>
> <Connector port="443"
> protocol="HTTP/1.1"
> maxThreads="150"
> sessionTimeout="7200"
> scheme="https"
> secure="true"
> SSLEnabled="true"
> sslProtocol="TLS"
> keystoreFile="conf/keystore-pkcs12"
> keystoreType="pkcs12"
> keyAlias="tomcat"
> keystorePass="secret"
> clientAuth="false"
> truststoreFile="/etc/java-6-sun/security/jssecacerts"
> truststorePass="secret" />
>
> Oh yes, I should also point out that I realise clientAuth="false" probably renders the truststore parameters redundant. However, this same jssecacerts file is acceptable to tomcat when successfully opening the JKS keystore.
>
>> Dan
>
> I'm sorry to post such a long reply, but it should probably have been even longer!
This was perfect! Now we know exactly what has been done in your environment. If I get a few spare minutes, I may even see if I can recreate the problem in my test environment.
Dan
>
> While writing this reply and thinking about my sequence of commands, I suspect the problem might boil down to some difference between the two keystores when they are initially created. Unfortunately, their different formats mean I have to use different tools to inspect their contents, which makes comparison difficult.
>
> I'm beginning to think that I will have to hang a debugger on to tomcat and follow the logic when the pkcs keystore is unwrapped.
>
> <snip/>
>
> Thanks for your thoughts,
>
> Brian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
Posted by Brian Burch <br...@pingtoo.com>.
On 26/10/12 13:24, Daniel Mikusa wrote:
> On Oct 26, 2012, at 5:11 AM, Brian Burch wrote:
>
>> My production tomcat 7.0.26 (and its predecessors back as far as tc 5) have been running with its original SSL server certificate in a JKS keystore for many years.
>>
>> I decided to retire my ancient java-based Certificate Authority and create a new CA using openssl 1.0.1 under ubuntu linux.
>
> Just my $0.02, but if you are just using Java based applications, stick with keytool. It will save you time.
Well, yes, that was true for me too Dan (see case 2 below). But the
tomcat wiki describes how to support pkcs12 and it ought to work (or say
under what circumstances it will not).
>> I followed the guidance in http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File
>>
>> I thought it would be sensible to generate all my new certificates and keystores using only openssl, so that I could use the same procedures for java and non-java applications. This meant I needed to produce a PKCS12 keystore for tomcat to use.
>>
>> I hit a succession of problems and resolved them, so I thought it would be helpful to update the wiki once I had a keystore that worked properly (details of tips and gotchas available).
>>
>> There are a lot of variables that I've explored, but I haven't yet succeeded with my "pure openssl" approach.
>
> I believe that what you are trying to do should work. It might be easier to debug if we could see a list of the commands that you've run. Maybe just copy and paste your shell session?
Thanks for your interest, Dan. I've gone through all the steps in my
notes carefully, and done my best to confirm these results.
1. Verify the openssl self-signed CA certificate (rsa 2048 bit key)
1.1. openssl x509 -noout -text cacert.pem displays OK.
1.2. strip all lines before "-----BEGIN CERTIFICATE-----" and after
"-----END CERTIFICATE-----"
1.3. keytool -printcert -file cacert-bare.pem displays the self-signed
certificate and extensions.
------------------------
2. create a JKS keystore and issue a cert with the openssl CA
2.1. keytool -genkeypair -alias tomcat -keyalg RSA -keysize 1024
-keystore jks-keystore -validity 2000 -dname
"CN=www.mydomain.com,OU=servers,O=mydomain.com"
.. using the same passphrase for the private key and the keystore.
2.2. keytool -list -v -keystore jks-keystore displays the RSA key
wrapped with a self-signed certificate.
2.3. keytool -certreq -keystore jks-keystore -file jks-req -alias tomcat
2.4. issue the new certificate from the openssl CA, AND THEN strip
everything from the file outside the delimiters.
2.5. keytool -printcert -file jks-servercert-bare.pem displays the
ca-signed certificate and extensions.
2.6. keytool -importcert -keystore jks-keystore -file cacert-bare.pem
-alias "Certificate Authority"
2.7. keytool -importcert -keystore jks-keystore -file
jks-servercert-bare.pem -alias "tomcat"
2.8. keytool -list -v -keystore jks-keystore shows the keystore contents
as two entries:
2.8.1. the first has an alias of tomcat, a private key entry and the two
certificates which comprise the complete chain.
2.8.2. the second has an alias of "Certificate Authority", with only the
CA's certificate.
Observation 2.8.2 indicates that I have put too much into this
certificate store and that step 2.6 was redundant. Nevertheless, tomcat
is perfectly happy to start its SSL Connector using this keystore.
------------------------
3. create a PKCS12 keystore and issue a cert with the openssl CA
3.1. CA.pl -newreq, with appropriate parameter values for the DN of the
server and an RSA 1024 bit key pair. This command creates newkey.pem and
newreq.pem files, both without any text before or after the delimiter lines.
3.2. openssl rsa -noout -text -in newkey.pem opens and prints the
contents of the key pair.
3.3. openssl req -noout -text -in newreq.pem opens and prints the
contents of the certificate request, including the server's new public key.
3.4. CA.pl -sign, issues the server certificate. It is prefixed with a
text representation of the contents.
3.5. Strip everything outside the delimiters from the newcert.pem file.
3.6. openssl x509 -noout -text -in newcert-bare.pem opens and prints the
contents of the certificate, including the server's public key.
3.7. openssl pkcs12 -export -in newcert-bare.pem -inkey newkey.pem -name
"tomcat" -chain -CAfile cacert-bare.pem -caname "Certificate Authority"
-out keystore-pkcs12 (using the same password for the keystore as the key).
3.8. openssl pkcs12 -noout -info -in keystore-pkcs12 -- displays the
kinds of things in the binary file, i.e.
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
3.9. keytool -list -keystore keystore-pkcs12 -storetype pkcs12 --
displays the kinds of things in the binary file, i.e.
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
tomcat, 30-Oct-2012, PrivateKeyEntry,
Certificate fingerprint (MD5):
80:4A:98:FD:73:DB:9B:E0:EE:3D:C6:82:75:7A:95:DE
However, tomcat fails to start its SSL Connector using this keystore
with the log messages below:
>> I do have a PKCS12 keystore that keytool (with the -storetype pkcs12 option) can list perfectly, but tomcat cannot open (with keystoreType="pkcs12" in the Connector). Both tomcat, and keytool are running from java-6-sun-1.6.0.26/jre/lib/i386. The log shows:
>>
>> 17-Oct-2012 15:33:51 org.apache.coyote.AbstractProtocol init
>> SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"]
>> java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
>> at sun.security.util.DerInputStream.getLength(DerInputStream.java:544)
>
> Please include your connector configuration.
<Connector port="443"
protocol="HTTP/1.1"
maxThreads="150"
sessionTimeout="7200"
scheme="https"
secure="true"
SSLEnabled="true"
sslProtocol="TLS"
keystoreFile="conf/keystore-pkcs12"
keystoreType="pkcs12"
keyAlias="tomcat"
keystorePass="secret"
clientAuth="false"
truststoreFile="/etc/java-6-sun/security/jssecacerts"
truststorePass="secret" />
Oh yes, I should also point out that I realise clientAuth="false"
probably renders the truststore parameters redundant. However, this same
jssecacerts file is acceptable to tomcat when successfully opening the
JKS keystore.
> Dan
I'm sorry to post such a long reply, but it should probably have been
even longer!
While writing this reply and thinking about my sequence of commands, I
suspect the problem might boil down to some difference between the two
keystores when they are initially created. Unfortunately, their
different formats mean I have to use different tools to inspect their
contents, which makes comparison difficult.
I'm beginning to think that I will have to hang a debugger on to tomcat
and follow the logic when the pkcs keystore is unwrapped.
<snip/>
Thanks for your thoughts,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
Posted by Daniel Mikusa <dm...@vmware.com>.
On Oct 26, 2012, at 5:11 AM, Brian Burch wrote:
> My production tomcat 7.0.26 (and its predecessors back as far as tc 5) have been running with its original SSL server certificate in a JKS keystore for many years.
>
> I decided to retire my ancient java-based Certificate Authority and create a new CA using openssl 1.0.1 under ubuntu linux.
Just my $0.02, but if you are just using Java based applications, stick with keytool. It will save you time.
>
> I followed the guidance in http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File
>
> I thought it would be sensible to generate all my new certificates and keystores using only openssl, so that I could use the same procedures for java and non-java applications. This meant I needed to produce a PKCS12 keystore for tomcat to use.
>
> I hit a succession of problems and resolved them, so I thought it would be helpful to update the wiki once I had a keystore that worked properly (details of tips and gotchas available).
>
> There are a lot of variables that I've explored, but I haven't yet succeeded with my "pure openssl" approach.
I believe that what you are trying to do should work. It might be easier to debug if we could see a list of the commands that you've run. Maybe just copy and paste your shell session?
> I do have a PKCS12 keystore that keytool (with the -storetype pkcs12 option) can list perfectly, but tomcat cannot open (with keystoreType="pkcs12" in the Connector). Both tomcat, and keytool are running from java-6-sun-1.6.0.26/jre/lib/i386. The log shows:
>
> 17-Oct-2012 15:33:51 org.apache.coyote.AbstractProtocol init
> SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"]
> java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
> at sun.security.util.DerInputStream.getLength(DerInputStream.java:544)
Please include your connector configuration.
Dan
>
>
> To understand the problem better, I started again by using keytool -genkeypair and then -certreq. I issued the new certificate with openssl and then imported the certificate chain into the JKS keystore.
>
> At this point I don't actually have a problem, because both keytool and tomcat are satisfied with the new keystore and my production system has been converted successfully.
>
> I hit some problems with this second approach (keytool genkepair), and so I could add a few notes to the wiki entry. However, I'm bothered that I couldn't get the first approach to work (pure openssl with pkcs12).
>
> google throws up a lot of matches for the DerInputStream.getLength error - even one from Mark Thomas about tomcat 4! I found a lot of red herrings, and a few useful ideas, but nothing to resolve my problem.
>
> It isn't encouraging to see "man pkcs12" ending with the sentence "Some would argue that the PKCS#12 standard is one big bug :-)", and yet JKS has to be a dead-end approach because it only applies to java.
>
> I have another system with java-7-openjdk-i386, but I haven't yet done any work on it. This openjdk does not ship with a keytool program, and so I presume it will use openssl.
>
> I wonder whether I have hit a sun java 6 (and 7?) bug that is of limited interest - does anyone have any thoughts?
>
> Thanks..
>
> Brian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
Posted by Brian Burch <br...@pingtoo.com>.
On 26/10/12 16:12, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brian,
>
> On 10/26/12 5:11 AM, Brian Burch wrote:
>> I have another system with java-7-openjdk-i386, but I haven't yet
>> done any work on it. This openjdk does not ship with a keytool
>> program, and so I presume it will use openssl.
>
> I dunno about the i386 version, but I have /usr/bin/keytool installed
> by Debian package "openjdk-7-jre-headless" (x86_64).
Thanks for pointing that out Chris, I was just wrong when I said it
wasn't there - I was looking at a different machine.
The system under investigation has both keytool executables installed:
brian@shiraz:/usr/bin$ ls -l keytool
lrwxrwxrwx 1 root root 25 Jun 15 2008 keytool -> /etc/alternatives/keytool
then, following that symlink like this...
brian@shiraz:/etc/alternatives$ ls -l keytool
lrwxrwxrwx 1 root root 39 Apr 24 2009 keytool ->
/usr/lib/jvm/java-6-sun/jre/bin/keytool
also, just to make 100% sure...
brian@shiraz:/etc/alternatives$ sudo update-alternatives --display keytool
keytool - manual mode
link currently points to /usr/lib/jvm/java-6-sun/jre/bin/keytool
/usr/lib/jvm/java-6-openjdk-i386/jre/bin/keytool - priority 1061
slave keytool.1.gz:
/usr/lib/jvm/java-6-openjdk-i386/jre/man/man1/keytool.1.gz
/usr/lib/jvm/java-6-sun/jre/bin/keytool - priority 63
slave keytool.1.gz: /usr/lib/jvm/java-6-sun/jre/man/man1/keytool.1.gz
Current 'best' version is
'/usr/lib/jvm/java-6-openjdk-i386/jre/bin/keytool'.
in other words, if I run keytool WITHOUT an explicit path, I get the sun
version. However, I used an explicit path to java-6-sun in my tests.
Thanks very much for your comment. It prompted me to explicitly run both
keytools against both the "faulty" pkcs12 and the "good" JKS keystores.
Much to my alarm BOTH tests on the "good" JKS failed with...
keytool error: java.lang.Exception: Keystore file does not exist:
www2-java-JKS-keystore
Happily, it didn't take me long to discover that this was due to a
permissions problem: running the identical commands under sudo worked fine.
I'll conclude this educational branch of my thread by confidently
restating that both keytools are able to list both keystores
successfully, even though the pkcs12 keystore cannot be opened by tomcat
7 under java-6-sun (I haven't tried it under java-6-openssl).
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlCKqFYACgkQ9CaO5/Lv0PB7wACgoQsJwEBd0ZBbjDyEpcD9U+kq
> UZMAnj32nxYKFq6hK4zJZ7LDEEKAyOow
> =wZbM
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 10/26/12 5:11 AM, Brian Burch wrote:
> I have another system with java-7-openjdk-i386, but I haven't yet
> done any work on it. This openjdk does not ship with a keytool
> program, and so I presume it will use openssl.
I dunno about the i386 version, but I have /usr/bin/keytool installed
by Debian package "openjdk-7-jre-headless" (x86_64).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCKqFYACgkQ9CaO5/Lv0PB7wACgoQsJwEBd0ZBbjDyEpcD9U+kq
UZMAnj32nxYKFq6hK4zJZ7LDEEKAyOow
=wZbM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org