Installing Squid 3.0 on Fredora 11

  1. Install Squid in the normal fashion using yum or System -> Administration -> Add/Remove Software.
  2. Open the Squid configuration file by executing the following command:
    sudo gedit /etc/squid/squid.conf
  3. Change the value of the error_directory property so that it points to an actual directory. For example:
    error_directory /usr/share/squid/errors/English

    As opposed to

    error_directory /usr/share/squid/errors/en

    which didn’t exist on my system after the install had completed.

  4. If your current SELinux enforcing mode is set to "Enforcing" you’ll also need to perform the following steps.
  5. Create the following Type Enforcement file (the remaining steps assume the file name local.te):
    module local 1.0;
    
    require {
    	type var_run_t;
    	type unconfined_t;
    	type squid_t;
    	class file {open read getattr};
    	class process signal;
    }
    
    #============= squid_t ==============
    allow squid_t var_run_t:file {open read getattr};
    allow squid_t unconfined_t:process signal;

    N.B. The following steps will overwrite any existing module with the same name. To check if you already have a policy module called local go to System -> Administration -> SELinux Management, select "Policy Module" from the left-hand menu and enter "local" into the filter field. If you’ve already got a module called local simply edit the Type Enforcement file accordingly. For example:

    module mysquid 1.0;
  6. Edit accordingly, then execute the following script:
    dir=<your-dir-path>;
    sudo checkmodule -M -m -o $dir/local.mod $dir/local.te;
    sudo semodule_package -o $dir/local.pp -m $dir/local.mod;
    sudo semodule -i $dir/local.pp;

    N.B. The checkmodule command takes the Type Enforcement file, local.te, created in step 5 as its input.

  7. Got to System -> Administration -> Services. Start Squid.
  8. Cleanup any unwanted files created in steps 5 and 6.
Advertisements

Unit Testing HTTPS Clients with a Self-signed Certificate

Overview

A quick and easy way to eliminate 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 without making dangerous changes to your default trust store.

Steps

  1. Create a new keystore and associated key entry by executing the following command (N.B. The password values for the -keypass and -storepass options must be identical for Tomcat to work):
    keytool -genkey -alias tomcat -keyalg RSA -keypass <password> -keystore <user-home>/tomcat.jks -storepass <password>
    
  2. Enter and confirm your details.
  3. Uncomment the “SSL HTTP/1.1 Connector” entry in $CATALINA_BASE/conf/server.xml.
  4. Add keystoreFile and keystorePass attributes with the appropriate values. The result should now resemble the following:
    <!-- Define a SSL HTTP/1.1 Connector on port 8443
    	This connector uses the JSSE configuration, when using APR, the
    	connector should be using the OpenSSL style configuration
    	described in the APR documentation -->
    
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
    	maxThreads="150" scheme="https" secure="true"
    	keystoreFile="${user.home}/tomcat.jks" keystorePass="<password>"
    	clientAuth="false" sslProtocol="TLS" />
    
  5. Restart Tomcat and deploy your HTTPS constrained resources.
  6. Add a @BeforeClass method to any tests generating HTTPS requests. Use this method to set the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword system properties. For example:
    @BeforeClass
    public static void setUp() {
    	System.setProperty("javax.net.ssl.trustStore", "<user-home>/tomcat.jks");
    	System.setProperty("javax.net.ssl.trustStorePassword", "<password>");
    }
    
  7. JSSE now uses the new keystore created in steps 1 and 2 as opposed to the default, <java-home>/jre/lib/security/cacerts, trust store.

Scraping Sun Microsystems’ CertManager

Waiting for SCJD or SCEA results can be a bit of a pain. The lucky amongst you may get them in a couple of weeks. On the other hand, you could face a wait of up to six weeks.

To make life a little easier I decided to cobble together an HTML scraper to automate the checking process.

Figure 1. Screenshot

Although there are no binaries at this point in time, you can checkout the source code from SourceForge. For SVN details click the Develop tab.

Usage

According to the CertManager Test History page "tests are imported during regular business hours (GMT -07:00)".

Extending it

Adding your own service listener should be a pretty straightforward task: simply implement PropertyChangeListener and register with the service. As an example; if you live in a timezone other than GMT -07:00, and want to get notified ASAP, you could implement a listener to send an email, or SMS, once the specified test result has been found.