Re: environment-based properties files
Thanks Brandon for confirming the general approach. Thanks Mark for the suggestion to use Context/Environment parameters. I think that properties files would be easier, in that each application can have its own properties files maintained and source controlled separately. I wanted to confirm that it isn't a bad practice for some reason I hadn't considered. I greatly appreciate the responses. Toby *** Toby Lazar Capital Technology Group Email: tla...@capitaltg.com Mobile: 646-469-5865 *** On Fri, Jul 18, 2014 at 10:55 AM, Mark H. Wood mw...@iupui.edu wrote: On Thu, Jul 17, 2014 at 05:01:32PM -0400, Brandon M. Wagner, Triple Tech Inc. wrote: On Jul 17, 2014, at 3:54 PM, Toby Lazar tla...@capitaltg.com wrote: Hi, Say I have an application that uses a properties and/or XML file that changes per environment. I'd like to create the WAR once and promote it from TES - STAGE - PROD without modification. Is this approach sensible? Is there a recommended approach for externalizing it? Is it safe to append a folder to common.loader in catalina.properties that contains the properties file and just exclude that file from the built WAR file? I have used a properties file per environment by placing it in the lib directory (since it's already in the class path). I still include a properties file in the .war but it looks for an external one in tomcat first. You can incorporate a checksum if you are worried about modifications to the properties file. I guess you don't want to just set some Context parameters https://mhw.ulib.iupui.edu:8443/docs/config/context.html#Context_Parameters or Environment entries? https://mhw.ulib.iupui.edu:8443/docs/config/context.html#Environment_Entries -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
environment-based properties files
Hi, Say I have an application that uses a properties and/or XML file that changes per environment. I'd like to create the WAR once and promote it from TES - STAGE - PROD without modification. Is this approach sensible? Is there a recommended approach for externalizing it? Is it safe to append a folder to common.loader in catalina.properties that contains the properties file and just exclude that file from the built WAR file? Thanks, Toby *** Toby Lazar Capital Technology Group Email: tla...@capitaltg.com Mobile: 646-469-5865 ***
Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does
Another option I normally use that may work for you (just confirmed it for myself with tomcat): 1. Copy your private key and signed public certificate in PEM format into a single file looking like this: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,F2CCC247E25D . . . -END RSA PRIVATE KEY- -BEGIN CERTIFICATE- . . -END CERTIFICATE- 2. Run portecle 3. File -- New Keystore (JKS) 4. Tools - Import Key Pair... 5. Select your file, take the defaults. You'll need to provide the password for your private key if you had one. 6. Save your JKS file. Provide a password. 7. Reference it in your tomcat config. Omit the alias. Your server will now present just the signed public certificate but not any others in the chain. Once you get this working, you can update the JKS with portecle to add intermediate certs. HTH, Toby *** Toby Lazar Capital Technology Group Email: tla...@capitaltg.com Mobile: 646-469-5865 *** On Fri, Apr 4, 2014 at 5:01 PM, Mark Murphy jmarkmur...@gmail.com wrote: Sorry for the dumb questions, I am new to SSL, and want to understand what I am doing, not just run these instructions, and it should work. On Fri, Apr 4, 2014 at 5:00 PM, Mark Murphy jmarkmur...@gmail.com wrote: So let me try to understand what is going on here. I generate a keystore using keytool, that contains a key. At this point it is equal to a self signed certificate, and it works, but the browser complains that there is no CA. I then need to create a certificate request ad send that off to goDaddy. What is this? a public key that matches up with the private key? Then I have to import the certificates that goDaddy returns to me because that validates the private key that is already in the keystore? On Fri, Apr 4, 2014 at 4:46 PM, Mark Thomas ma...@apache.org wrote: On 04/04/2014 21:42, Mark Murphy wrote: I saw something on StackOverflow that said the key type in the keystore needs to be PrivateKeyEntry and not trustedCertEntry. Is this true? When I look at my keystore, it is trustedCertEntry for all the certs. But when I look at the type for the self signed certificate (which works), it shows keyEntry. Does, or should this matter? and if so, how do I change the type? Yes, this matters a lot. You must import the cert you receive from the CA into the same keystore you used to generate the CSR since that is where the private key is and the server has to have access to the private key. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valid certificate chain failing with unable to find valid certification path to requested
On Thu, Apr 3, 2014 at 2:58 PM, jeffery.scott.cr...@gmail.com wrote:
Chris,
Sent from Windows Mail
From: Christopher Schultz
Sent: Thursday, April 3, 2014 1:55 PM
To: Tomcat Users List
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeffrey,
On 4/3/14, 2:25 PM, jeffery.scott.cr...@gmail.com wrote:
I'm using tomcat 7.0.50 on CentOS 6.5 on a headless blade server;
8 processor cores, 18 GB RAM.
My java client is opening an HttpsURLConnection:
SSLContext sc = SSLContext.getInstance(TLS); sc.init(null, null,
null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
URL url = new URL(urlText);
HttpsURLConnection urlConnection = (HttpsURLConnection)
url.openConnection();
urlConnection.setHostnameVerifier(DO_NOT_VERIFY);
urlConnection.setDoOutput(true); try (OutputStreamWriter output =
new OutputStreamWriter(urlConnection.getOutputStream(), UTF-8))
{ output.write(msg.writeNodes(false)); output.write(\n);
output.flush(); }
Looks fairly innocuous.
On getting the urlConnection.getOutputStream() the following
exception is thrown:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building
failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
If I set the SSLContext to accept all hosts it works.
I can see the servlet's Hello World message from a web browser.
Chrome says that it has a valid certificate.
I verified that the certificates were valid using SSLShopper:
www.x.net resolves to xxx.xxx.xxx.xxx
Server Type: Apache/2.2.15 (CentOS) The certificate should be
trusted by all major web browsers (all the correct intermediate
certificates are installed). The certificate was issued by GoDaddy.
The certificate will expire in 364 days.
The hostname (www.xx.net) is correctly listed in the
certificate. Common name: www.x.net SANs:
www.xx.net, xx.net Valid from April 3, 2014 to
April 3, 2015 Serial Number: 0431cbc326fefc Signature Algorithm:
sha256WithRSAEncryption Issuer: Go Daddy Secure Certificate
Authority - G2
Common name: Go Daddy Secure Certificate Authority - G2
Organization: GoDaddy.com, Inc. Location: Scottsdale, Arizona, US
Valid from May 3, 2011 to May 3, 2031 Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
Certificate Authority - G2
Common name: Go Daddy Root Certificate Authority - G2 Organization:
GoDaddy.com, Inc. Location: Scottsdale, Arizona, US Valid from
August 31, 2009 to December 31, 2037 Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
Certificate Authority - G2
I have similar setup. The keystores are in the same folder, the
server.xml are the same except for the hostnames and the keystore
password. The server with the problem is not using the default
keystorepassword of changeit
JSSE is probably missing an intermediate or root CA certificate that
you need.
Are you saying that you have one server that works okay and another
that does not? If so, the problem is likely that your non-working
server requires an additional intermediate certificate that most
browsers have, but that JSSE does not. (JSSE does not really keep up
well, honestly.)
Are either of the GoDaddy certs above served directly by your web
server? Your chain length is 3 (from CA root to your cert), but the
question is whether you are serving only 1 (your own) or 2 (your own +
GoDaddy's intermediate) certificates.
If you can ship a trust store with the client, then you can add
whatever (root or otherwise) certificates you need to trust. The code
is a little messy, but I was able to adapt code I borrowed from Tomcat
to allow me to connect to an HTTPS endpoint using an on-disk trust
store and HttpURLConnection.
Let me know if that code would be useful to you.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPa6YAAoJEBzwKT+lPKRYWO0QAI01lRXekr8ARVi/+HBcrxfZ
8gaBiWQR8Ce2Vv+U2AGP5m6bQQNCsOGkr04PdnYJSphTKJcOfbWCNyrMXMkNFwNs
N44t4Fgye3el1CoBxZo5SVFKqnfZLjDLV0vYtuMlG4frObMw/s3OXC4Hb1X7E60F
PGe0WOZtBe4pf4xSGfgERgdZuSaJH8eWoCUMHnY78sCFH/M8iAxcG6SzniKPxke2
BwAqNuENaVLvNw/uiAbgtIwdqfYCUFiV2UKyG/E++v7nQEJM7iK/+AKzNejdefo/
H0zmIdDNWKtCpP1wbnjgKxKd6/z7w6p/4WQUsDP5iFroI8xymsVkdAOqiM6zB9gP
4neQFQfKuMrU7h5iWhGoVGqe4Vmo9Q7GzyczqXDsT93buEjy/XFcXiPtiayIsMbi
b4MCRvd0jwTVZxDy0BnsnzUpfSnJetgXC/r3lA579cDTq5Q7GJAOSzlP3fCCCA5N
k2Jb/lHeeuFXokYhbUq5KvgJYh8DOjSOSoHY1A+kU0/jwqNzAXpJCmBEv/1z+apo
6mWd1+AmC2PyB7nfX9rtIxGeodErUHnUfHbRJKmK6wEipcJ4bbBbXS/OfdsMPi2f
Qdqjw3Bv+8/zEa3Pq4mc8ZegUk2bqMof1z0ycxpyjChdFfxIOM3FG5QvE6fJqREn
9BsFBBA21UryM6HZNVXt
=dXBw
-END PGP SIGNATURE-
Re: Valid certificate chain failing with unable to find valid certification path to requested
On Thu, Apr 3, 2014 at 10:03 PM, jeffery.scott.cr...@gmail.com wrote: I tried ssllabs but it doesn't support SSL on port 8443, but digicert did show that everything was correct in the chain. Your certificate is a good certificate but it doesn't mean your client should trust it. ssllabs may trust a different set of issuers than your client. I've run my client program with the -Djavax.net.debug=all option. First it listed out all of the trusted authorities. Mine is GoDaddy and this is the record: That one is not the issuer of your certificate. GoDaddy has many issuing certificates. The GoDaddy certificate the client trusts expires in 2034 whereas your issuer certificates expire in 2031/2037. Also, the DNs are different. Better to identify the trusted certificate by serial number and subject key identifier. 04/03/2014 07:42:56 PM adding as trusted cert: 04/03/2014 07:42:56 PM Subject: OU=Go Daddy Class 2 Certification Authority, O=The Go Daddy Group, Inc., C=US 04/03/2014 07:42:56 PM Issuer: OU=Go Daddy Class 2 Certification Authority, O=The Go Daddy Group, Inc., C=US 04/03/2014 07:42:56 PM Algorithm: RSA; Serial number: 0x0 04/03/2014 07:42:56 PM Valid from Tue Jun 29 12:06:20 CDT 2004 until Thu Jun 29 12:06:20 CDT 2034 This is what I think is the relevant part: [3]: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:false PathLen:2147483647 ] I don't think this is your problem. Your problem is that you lack a chain of trust from your server certificate to one that the client already trusts. If your server is only serving up its own server certificate and not the intermediate one, try adding that to your config. You can test this out with portecle or another tool. Toby How can I tell what that is or how to remove it? Thanks, Jeff Sent from Windows Mail From: James H. H. Lampert Sent: Thursday, April 3, 2014 8:12 PM To: Tomcat Users List I've only barely glanced at this thread, so forgive me if I'm saying something that's already been mentioned, or that's irrelevant. But yesterday, I was tearing my hair out over something similar while setting up a keystore for a customer: it seems that the customer's CA of choice had assumed that the customer was using the same keystore that they'd used previously (I'd created a new one because of some changes in ownership and location information), and so they'd signed the CSR with the OLD intermediate certificates, without bothering to tell anybody. And so every time I tried to plug the response certificate in with the NEW intermediates, Keytool would balk. I dunno what possessed me to try the old intermediates, but try them I did (by that time, I'd also found and installed KeyStore Explorer, a nifty little open-source Keytool-replacement). (Ironically, because installing a CSR response certificate is a bit counter-intuitive in KeyStore Explorer [it's ONLY on the right-click menu, and ONLY if you right-click on a keypair], the keystore I made using it was worthless, but once I'd discovered the problem, I'd also done one with Keytool as a backup. Didn't find out I'd screwed up the KeyStore Explorer version until this afternoon, and didn't figure out the right way to do it in KeyStore Explorer until after I'd already put the Keytool version of the keystore into service.) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: old versions with parallel deployments
Thanks Mark for confirming and Chris for the reminder about HTML anchors. Any chance something like this may be implemented in the future? AppEngine provides this function via 1.appname.appspot.com, 2.appname.appspot.com, etc. Though relying on DNS names wouldn't be practical here, perhaps something similar like: /appname~version/ or /appname/version/ In my use case this would enable us to compare a PROD instance with a previous version without explicitly copying the previous WAR to: /appname_version or similar. Thanks for your time and consideration. Toby *** Toby Lazar Capital Technology Group Email: tla...@capitaltg.com Mobile: 646-469-5865 *** On Thu, Mar 13, 2014 at 11:41 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Toby, On 3/12/14, 11:03 PM, Toby Lazar wrote: If I deployed multiple versions of a single application using parallel deployments, is there a way I can access old versions of the app? Is there a way to go to version 001 using something like: /application##001 after version 002 is already deployed? I tried going to that URL but tomcat always takes me to the most recent version. Note that the # in the URL doesn't get sent to the server: the client uses that as the anchor for the page, and tries to locate an a name=[anchor] or element id=[anchor] in the page to bring into view. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTIdHDAAoJEBzwKT+lPKRYvmAP/Ahj6ZF1y1v453DdbMSUmodH aDjIZd5mEZ/N4q+eM//yL2Yi/haPnSEqwt5LDYORAGFn6A0G2mgBBzFdA7S50E5t 9tMeHm97XLQXZsR29Pz3c/l6AZbG1iwyb5hX2KCVxfpi6237TuGqClCAjMzXz5NR GTP1zsB/OOWyCwtcFRyWtOgH7vavm8jwUW9mQlvXuL1o8qvjzANHByeH/UI4ft94 jr00AHtObGszolH6m5ybFF8baJDGee/UPdZkGx96htPdPO6TafasgEuSuT0rk2pa n9m/whxFEY6Rm9dizsZUQiGRCUpLUNe0C57HVrAm6MSNZR+XTGRJH4zEVQi1e8sH Zv/MIYbh/h1ITmp7P6F5YP5OglJgbEyHU/EqWSi/3YP1IGiB5q44+DvenOC7WkZT v+9JbworiVYm5YMXXyWGOTA6U7I6Jf2SnHGR5WcXWpq4589PNblzVVolxGZfpw6E Sm3TfC9E1Op8YT+/3e53I6kejgyRrP4Gy/3RdCu9AraDg7K3ToovTbcvj04WhzBn tXIlqicyopzHTsqtPijIpZceUd2fWs1LJdG7XwOgLUNfe6rsWF/nOR5AcZk5RF4c qMYmlH+dJi1koV9d90ao1FMyGphQTU1izovobLPlsKTgaJKcCgFZN99jvI9lGeyt zZtZf3DPLmSXX/A/Uxu1 =xpM4 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
old versions with parallel deployments
If I deployed multiple versions of a single application using parallel deployments, is there a way I can access old versions of the app? Is there a way to go to version 001 using something like: /application##001 after version 002 is already deployed? I tried going to that URL but tomcat always takes me to the most recent version. Thanks, Toby *** Toby Lazar Capital Technology Group Email: tla...@capitaltg.com Mobile: 646-469-5865 ***
