Re: SSL BIO/NIO setup with openssl CA puzzle
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
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:
Re: SSL BIO/NIO setup with openssl CA puzzle
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
Re: SSL BIO/NIO setup with openssl CA puzzle
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL BIO/NIO setup with openssl CA puzzle
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL BIO/NIO setup with openssl CA puzzle
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: dmik...@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
Re: SSL BIO/NIO setup with openssl CA puzzle
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
