Tuesday, December 30, 2008

How to Generate a Self-Signed Cert for Java cacerts and Apache

The following describes how to generate a self-signed cert in the java keystore and then export out the cert and key so that Apache can use it.

How to Check for an Expired Cert

Command-line Check for an Expired Cert

* Print expired cert date:

echo "" | openssl s_client -connect server:443 > certificate

Creating/Renewing key in cacerts

Note: Replace yourhostname in the following with your hostname or virtual hostname

Remove old cert


${JAVA_HOME}/bin/keytool -delete -alias yourhostname.yourdomain.com -keystore ${JAVA_HOME}/jre/lib/security/cacerts

Create new cert (-validity 40000 basically means it should last for many years)


${JAVA_HOME}/bin/keytool -genkey -alias yourhostname.yourdomain.com -keystore ${JAVA_HOME}/jre/lib/security/cacerts -keyalg rsa -validity 40000
Enter keystore password: changeit
What is your first and last name?
[Unknown]: yourhostname.yourdomain.com
What is the name of your organizational unit?
[Unknown]: Office of Information Technology
What is the name of your organization?
[Unknown]: Duke University
What is the name of your City or Locality?
[Unknown]: Durham
What is the name of your State or Province?
[Unknown]: North Carolina
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=confluence-test.domain.org, OU=Office of Information Technology, O=Duke University, L=Durham, ST=North Carolina, C=US correct?
[no]: y

Enter key password for <yourhostname.yourdomain.com>
 (RETURN if same as keystore password):
If this fails with "keytool error: java.io.FileNotFoundException: ${JAVA_HOME}/jre/lib/security/cacerts (Permission denied)", you need appropriate permissions on cacerts:

cd ${JAVA_HOME}/jre/lib/security
chmod 644 cacerts
(repeat step above)

Exporting cert to apache using openssl

This info is from http://mark.foster.cc/kb/openssl-keytool.html * Once the alias has been identified we can do the extraction.

${JAVA_HOME}/bin/keytool -keystore ${JAVA_HOME}/jre/lib/security/cacerts -export -alias yourhostname.yourdomain.com > /tmp/yourhostname.der.crt
* The result is a DER (binary) formatted certificate in /tmp/yourhostname.der.crt. It can be viewed using:

openssl x509 -noout -text -in /tmp/yourhostname.der.crt -inform der
* You will want to convert it to another format - PEM - which is more widely used in applications such as apache and postfix.

openssl x509 -out /tmp/yourhostname.yourdomain.com.pem.crt -outform pem -text -in /tmp/yourhostname.der.crt -inform der
* The resulting file can now be referenced from apache, postfix, etc as the CA certificate.

Copy cert to Apache

* Copy key (/tmp/yourhostname.yourdomain.com.pem.crt) to apache cert dir as yourhostname.yourdomain.com.crt, and you'll probably want to back up the old file first

cp /etc/httpd/conf/ssl.crt/yourhostname.yourdomain.com.crt /etc/httpd/conf/ssl.crt/yourhostname.yourdomain.com.crt.old.todaysdate
cp /tmp/yourhostname.yourdomain.com.pem.crt /etc/httpd/conf/ssl.crt/yourhostname.yourdomain.com.crt

Exporting private key from cacerts to apache

_partially from_ _[http://mark.foster.cc/kb/openssl-keytool.html]_ * If you have Java 1.5 or later you may be able to use the attached class [ExportPriv.class|^ExportPriv.class] (go to Attachments and click on it to download it), or follow the instructions below to compile it on your own The original [ExportPriv|http://mark.foster.cc/pub/java/ExportPriv.java] crafted from Andrew Morrow's posting at [http://forum.java.sun.com/thread.jsp?forum=2&thread=154587&message=449486]. The key will be produced to STDOUT. Was suggested that you redirect > to exported.key

Compile ExportPriv.java

From http://mark.foster.cc/pub/java/ExportPriv.java crafted from Andrew Morrow's posting.

javac ExportPriv.java
java ExportPriv <keystore> <alias> <password> > exported-pkcs8.key

Extract the Private key

* The ExportPriv java command-line utility either needs to be run from the server itself, or you can scp its cacerts file to a different location to extract it.

scp /tools/*xport\* (server):/tmp
ssh and change ownership as needed
CLASSPATH=.
${JAVA_HOME}/bin/java ExportPriv ${JAVA_HOME}/jre/lib/security/cacerts yourhostname.yourdomain.com changeit > exported-pkcs8.key
* The private key is being exported as PKCS#8 PEM format. To get it into the RSA format that works with Apache (see below) you can issue the following command:

openssl pkcs8 -inform PEM -nocrypt -in exported-pkcs8.key -out yourhostname.yourdomain.com.key
Warning: don't make this key available anywhere publicly. That defeats the purpose of it (is supposed to be private).

Copy Key to Apache

* Copy key (yourhostname.yourdomain.com.key) to apache key dir, and you'll probably want to back up the old file first

cp /etc/httpd/conf/ssl.key/yourhostname.yourdomain.com.key /etc/httpd/conf/ssl.key/yourhostname.yourdomain.com.key.old.todaysdate
cp yourhostname.yourdomain.com.key /etc/httpd/conf/ssl.key/yourhostname.yourdomain.com.key

Updating Config of Applications that Use the Cert

* If you are using something else that uses that cert (in our case was Shibboleth), you may need to update all references to the cert and key in /etc/shibboleth/shibboleth.xml or you could just backup the old server.crt and server.key and overwrite them with the new one if it is the default server cert and key.

Restarting Apps

* After updating don't forget to restart any external services/apps using the cert

Updating Apache Config

* If needed, update the /etc/httpd/conf.d/ssl.conf or whichever conf file refers to the cert and key * If you're not sure where it is you could grep for it:

cd /etc/httpd/conf.d/
grep -H ".crt" *
grep -H ".key" *
* If you don't find it, you'll need to look into configuring apache with the key. Note: Watch out for external applications that maybe synchronizing configs such as Glump. It may overwrite your changes. Check to determine the proper way to update config.

Restarting Apache


/sbin/service httpd restart

Contact Anyone Who Might Care About a Cert Change

* In our case we needed to contact the Shibboleth IdP folks. You may want to suggest that a different self-signed cert be used for the SSO.

New Software Architectural Pattern: The Interaction-Flow-Service-Model Architectural Pattern (IFSM)

If you're interested in software architectural patterns, check out the Interaction-Flow-Service-Model Architectural Pattern (IFSM). Follow-up posts: * Isolation of Flow from Services using the IFSM pattern

"Error occurred: too many HTTP redirects" error in Dejal Simon with uPortal 2.5.3

I just figured out an issue with Dejal Simon 2.4.2 monitoring uPortal 2.5.3 and thought I'd share, because it might apply to others as well. The Simon tests we were using had recorded previous cookies (__utma, __utmb, __utmz, NSC_9803..., WT_FPC) which may have had to do with our Webauth here (or maybe is uPortal, don't know). After a reboot of the computer (MacPro1,1 Dual-core Xeon, Panther) after the latest OS X update, whenever it tried to access the uPortal sites, it got into an infinite redirect loop (it was getting "Error occurred: too many HTTP redirects"). When I removed the cookies from the tests that had that error, the tests started working again. I know that removing cookies won't always help the "Error occurred: too many HTTP redirects" situation (sometimes it might be a valid error!), but just thought I'd offer this as a possible fix if anyone else runs into this. I had gotten sidetracked a bit in the process because I also learned that Simon sends out the user-agent header "Simon2043 CFNetwork/422.11 Darwin/9.6.0 (i386) (MacPro1%2C1)", and when I used the Modify Headers plugin in Firefox 3.0.5 to send that user-agent, uPortal returned a page saying it didn't recognize the user-agent and asking the client to choose WML or HTML. But, I guess that Simon has been getting that page all along which is ok because we just need a quick test to make sure the webapp is up. Hope this helps someone else, Gary Also posted this solution here: * http://www.dejal.com/forums/2008/12/30/error-occurred-too-many-http-redirects-fixed-our-case-removing-cookies-tests

Monday, December 29, 2008

Friday, December 19, 2008

How to Recover from Portlet Error: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name

If you get the following error in a portlet (this one is from pluto 1.0.1):

ERROR [main] Dec/18 10:49:31,858 digester.Digester.[] - End event threw exception
java.lang.reflect.InvocationTargetException
 at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.tomcat.util.IntrospectionUtils.callMethodN(IntrospectionUtils.java:929)
 at org.apache.tomcat.util.digester.CallMethodRule.end(CallMethodRule.java:578)
 at org.apache.tomcat.util.digester.Rule.end(Rule.java:228)
 at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1057)
 at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
 at org.apache.xerces.impl.dtd.XMLDTDValidator.endNamespaceScope(Unknown Source)
 at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(Unknown Source)
 at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(Unknown Source)
 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561)
 at org.apache.catalina.startup.ContextConfig.applicationWebConfig(ContextConfig.java:351)
 at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1041)
 at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:260)
 at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4143)
 at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
 at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)
 at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
 at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
 at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
 at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
 at org.apache.catalina.core.StandardService.start(StandardService.java:450)
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
Caused by: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name eventsportlet
 at org.apache.catalina.core.StandardContext.addServletMapping(StandardContext.java:2322)
 at org.apache.catalina.core.StandardContext.addServletMapping(StandardContext.java:2302)
 ... 46 more
It more than likely means that the portlet was not "plutofied" (web.xml altered by Pluto). For information on how to plutofy a portlet in uPortal, see http://stufftohelpyouout.blogspot.com/2008/09/automate-uportal-deployportletapp.html!

Saturday, December 6, 2008

Thursday, December 4, 2008

Top Level Domain (TLD) Current List and Stats

Internet Systems Consortium serves some recent stats on TLD usage produced by 3waylabs. I wanted to know what ".sg" was since I saw it in a spam, and it appears to be from Singapore. * Distribution of Top-Level Domain Names by Host Count * More stats

How to Create a Patch with Subversion and Apply a Patch with Patch

A much better description can be found here: * http://ariejan.net/2007/07/03/how-to-create-and-apply-a-patch-with-subversion/ How to create a patch in subversion/how to create a diff file in subversion:

svn diff > ~/fix_name.diff
How to apply a patch:

patch -p0 -i ~/fix_name.diff

Wednesday, December 3, 2008

SpringSource Enterprise Bundle Repository

This is a pretty nifty tool to find Spring dependencies in copy/paste format for Ivy, Maven, or MANIFEST.MF: * http://www.springsource.com/repository/app/

Monday, December 1, 2008

Choosing a Java Web Framework

I just wanted to do a quick lookup to find what was going on in the Java Web Framework scene and have found quite a number of frameworks. Sorry for the lack of links here. I just didn't have time to look them all up! Matt Riable's top list at the beginning of the 2008 were: 1. JSF/Seam 2. GWT 3. Grails 4. Tapestry 5 5. Wicket 6. JRuby on Rails (or RIFE) 7. Struts 2 8. Spring MVC Primarily in early 2008, the most well-used were Struts 1 and 2, Spring MVC + Spring WebFlow, and JSF. However, there are a number of people using Wicket, Tapestry, Grails (which also uses Spring MVC + WebFlow), JRoR/RIFE, or GWT. And Stripes and ZK also get some buzz. Sorry if I've left out a bunch. A much longer list was presented in the 2008 JavaOne in in a presentation called "Choosing a Java Web Framework", by Richard Pack, which was: * Action Framework * Anvil * Aranea * Aurora * Baritus * Barracuda * Bento * Bishop * Canyamo * Cassandra * Chiba * Chrysalis * Click * Cocoon * Dinamica * Dovetail * DWR * Echo * Expresso * fleXive * Folium * Groovy/Grails * GWT * Helma * Jacquard * Jaffa * Japple * JATO * JFormular * JOSSO * JPublish * JSF * JSPWidget * Jucas * Junction * JWAA * JWarp * jWic * jZeno * jZonic * Macaw * Makumba * Maverick * Melati * Mentawai * Millstone * MyFaces * Nacho * Niggle * OpenEmcee * OpenXava * OXF * Pustefix * Restlet * RIFE * RSF * Seam * Shocks * Smile * SOFIA * Spring MVC * Strecks * Stripes * Struts * Struts 2 * SwingWeb * Tapestry * TeaServlet * ThinWire * Trimpath * Turbine * Verge * VRaptor * Warfare * WebOnSwing * WebWork * Wicket * wingS * Xoplon * ZK * ztemplates (Note: the author admits there are over a hundred and this is only 81. Other notables not listed that I read about: Lift) Links: * http://ptrthomas.wordpress.com/2007/03/02/wicket-impressions-moving-from-spring-mvc-webflow/ * http://forums.thedailywtf.com/forums/p/8656/164187.aspx * http://stackoverflow.com/questions/309254/best-java-mvc-framework-implementation-for-web-apps * http://raibledesigns.com/rd/entry/java_web_framework_smackdown_at

Collaborative Real-time Online Text Editor - Etherpad

Etherpad is a collaborative real-time online text editor that Richard just showed me. It lets you see your changes and others immediately, unlike a wiki where you have to save changes before the other person can see your changes. This type of tool is great for when you need to hammer out documentation or a configuration file with one or more people at once. We used it to edit wiki page contents of a summarized to-do list for a meeting discussion that Richard was going to. * http://etherpad.com/