Creating an easy to deploy SSL certificate in PEM format

When ordering a secure certificate, most often one has to deal with the following files:

  • certificate key file (aka private key): .key
  • certificate request file: .csr
  • primary certificate file (issued by the CA): .crt
  • certificate chain (aka intermediate certificate, or sf bundle): sf_bundle.crt

As a result, when deploying to a web server, it is necessary to configure 3 files: the key, the cert, and the trust chain. However, a little known fact is that these can be combined in a “pem” file that holds all three. One may even include the trusted root certificate optionally. Here is how:

  • download your certificates (your_domain_name.crt) from your NewPush Customer Portal.
  • paste the entire body of each certificate one by one into one text file in the following order:
    • domain.key
    • domain.crt
    • sf_bundle.crt

    Make sure to include the beginning and end tags on each certificate. The result should look like this:

    -----BEGIN RSA PRIVATE KEY-----
    ...
    -----END RSA PRIVATE KEY-----
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

The number of

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

sections will depend of the length of the certificate trust chain.


Qpid, an AMQP implementation

Joshua Kramer has an article in LJ about Qpid and AMQP. One of the most compelling aspects of Qpid is its cross plaform and cross language capability. Finally there is a message broker that is easy to use and has ready to go clients for C++, Java, Python, Ruby and .Net. Take a look and let me know what you think.


Setting up Apache Authentication with htpasswd / htaccess

Authentication in Apache is done through htaccess, either from the configuration file, or from the .htaccess file in a given directory. Note that only full directories can be easily protected with this method.
Here is how: (first log in to the shell, as this method only works if
you have shell access)

$ cd .../html/protected_dir

$ cat > .htaccess

AuthType Basic

Authname "Protected KLC directory"

AuthUserFile ../../control/htpasswd

AuthGroupFile /dev/null

Require valid-user

+d

$ htpasswd -c ../../control/htpasswd user_name

[give passwd]

After the file is created for the first time, to
add more users:

$ htpasswd ../../control/htpasswd user_name

There are also more sophisticated authentication schemes available, that allow database driven authentication. Feel free to contact me for more information about those solutions.


Connection pooling with mod_perl

I found this info in the PostgreSQL archives. Here are  2 methods:

Best method from Dan Lyke: Apache::DBI will pool across Perl programs, and you don’t have to change anything in your scripts.

Next best method from Gilles DAROLD: in your perl script use the following code

use vars qw($dbh);

$dbh ||= DBI::connect($datasrc, $dbuser, $dbpwd);

These can be use to create a database connection class in Perl that can handle transparently the connection / reconnection and disconnection for your code. The end use code doesn’t have to be OO, thus the connection object can be reused in any legacy code.


How to avoid the phpBB worm with Apache Rewrite Engine

This solution was suggested by Raymond Dijkxhoorn on BugTraq:

If you cannot fix it (virtual servers) fast for all your clients you could also try with
something like this:

        RewriteEngine On
        RewriteCond %{QUERY_STRING} ^(.*)echr(.*) [OR]
        RewriteCond %{QUERY_STRING} ^(.*)esystem(.*)
        RewriteRule ^.*$                                -               [F]

We had some vhosts where this worked just fine. On our systems we didnt see any valid
request with echr and esystem, just be gentle with it, it works for me, it could work
for you ;)


How to make perl work in a chrooted Apache on OpenBSD 4.5

I found this solution on the misc@ list, and just slightly had to update it:

 Getting Perl/CGI to work in a chroot'd Apache environment :

Intentions

Let me start off by saying that allowing Perl/CGI in a server
environment is generally a not good idea, unless you like to
spend all of your time auditing the Perl/CGI scripts on your
webserver. Lets face it - a lot of the Perl/CGI code out there
is very poorly written security wise and can present a serious
threat to your business or organization. Crackers know this and
will try to exploit the vulnerabilities in your Perl/CGI scripts
to gain access to your system(s).

Nonetheless, since the OpenBSD 3.2 release with the default
chroot'd Apache, I have been getting a lot of e-mails regarding
problems that users and admins have encountered. For example,
admins like the idea of running Apache in chroot, but their
websites rely heavily upon multiple Perl/CGI scripts. With Apache
running in chroot, Perl/CGI will obviously not work by default.
The dillema here, is that admins do not want to sacrifice the
security of running chroot'd Apache, but at the same time, they
cannot operate their business or oganization successfully without
the Perl/CGI applications. So, this paper was written specifically
for that reason - being able to run Apache in chroot with Perl/CGI
capabilities.

* Requirements

This document is specifically written for users and admins of
OpenBSD=>3.2 with chroot'd Apache, but it can be applied to
other operating systems/distributions if the Apache setup follows
the OpenBSD chroot'd Apache setup. If you are an experienced
admin running a different operating system/distribution, this
document can give you the general idea on what to do.

+ OpenBSD=>3.2
+ Perl
+ Default chroot'd Apache

* Instructions

By default, chroot'd Apache is in /var/www. Since Apache cannot
see outside /var/www, we will have to recreate a few directories
for Perl, so it could still be called from scripts with
#!/usr/bin/perl :

root@openwire # cd /var/www
root@openwire # mkdir usr; mkdir usr/lib; mkdir usr/libexec; mkdir usr/bin

Now that the directories have been created, we have to see what
libraries perl depends on :

root@openwire # ldd /usr/bin/perl
/usr/bin/perl:
-lperl.8 => /usr/lib/libperl.so.8.0 (0x4001d000)
-lm.1 => /usr/lib/libm.so.1.0 (0x400fa000)
-lc.29 => /usr/lib/libc.so.29.0 (0x4010e000)
-lutil.8 => /usr/lib/libutil.so.8.0 (0x401cc000)

Copy those libraries to the correct directories in /var/www/usr/* :

root@openwire # cp /usr/lib/libperl.so.8.0 /var/www/usr/lib/
root@openwire # cp /usr/lib/libm.so.1.0 /var/www/usr/lib/
root@openwire # cp /usr/lib/libc.so.29.0 /var/www/usr/lib/
root@openwire # cp /usr/lib/libutil.so.8.0 /var/www/usr/lib/

Copy ld.so to /var/www/usr/libexec :

root@openwire # cp /usr/libexec/ld.so /var/www/usr/libexec/

Copy perl to /var/www/usr/bin :

root@openwire # cp /usr/bin/perl /var/www/usr/bin

Now adjust your /var/www/conf/httpd.conf file as usually by
adding :

AddHandler cgi-script .cgi
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

AllowOverride None
Options Indexes FollowSymLinks ExecCGI
Order allow,deny
Allow from all

Restart Apache :

root@openwire # apachectl restart
/usr/sbin/apachectl restart: httpd restarted

As well as what others have mentioned, you may find that
  apachectl restart
doesn't quite work the same because the restart is already chrooted.
Any problems:
  apachectl stop; sleep 1; apachectl start
may solve.

That's it. If you have done everything as said in this document,
you should have access to Perl/CGI on your chroot'd Apache.
Good luck.

* Credits

This document is Copyright 2003 by Daniel Selans (metawire system
administrator)

Dom De Vitto has contributed the apachectl restart workaround.


How to fix mod_perl with Apache2 on Ensim 3.7.x and Ensim 4.0.x?

Fixing mod_perl

Based on Ensim Knowledge ID:964

Description:
mod_perl fails with Apache 2.0 on Ensim Pro/Basic

Solution:

When using Apache 2.0 with Ensim Pro/Basic, mod_perl no longer functions.  This is due to improper module references.  Ensim will provide an official fix in an upcoming Erratum.  A symptom of this error will be the following error information in /var/log/httpd/error_log

[Wed May 19 13:42:14 2004] [error] failed to resolve handler `Apache::Registry’
[Wed May 19 13:42:14 2004] [error] [client 67.172.191.228] Can’t locate loadable object for module Apache::Constants in @INC (@INC contains: /usr/lib/perl5/5.8.1/i386-linux-thread-multi /usr/lib/perl5/5.8.1 /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.1/i386-linux-thread-multi /usr/lib/perl5/5.8.1 . /etc/httpd/ /etc/httpd/lib/perl) at /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/mod_perl.pm line 14
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Apache.pm line 6.
BEGIN failed–compilation aborted at /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Apache.pm line 6.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Apache/Registry.pm line 2.
BEGIN failed–compilation aborted at /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Apache/Registry.pm line 2.
Compilation failed in require at (eval 1) line 3.

Applies to:

 

 Products:

 Ensim Pro, Ensim Basic

 

 Versions:

 3.7.x, 4.0

 

 Platforms:

 Red Hat Enterprise, Fedora

Instructions:

mkdir /root/working
cd /root/working
wget 
ftp://ftp.Ensim.com/outgoing/kb/mod_perl/mod_perl.pyc.gz
gunzip mod_perl.pyc.gz
cp /usr/lib/python2.2/site-packages/vh3/modules/mod_perl.pyc /root/working/mod_perl.pyc.backup
cp mod_perl.pyc /usr/lib/python2.2/site-packages/vh3/modules/mod_perl.pyc
service webppliance restart
for i in $(sitelookup -a site_handle); do EditVirtDomain $i; done
rpm -e mod_perl-httpd13


How to upgrade Chili!ASP (SUN One ASP)

The modules need to be recompiled for the new version of Apache. Here are the steps:

  # mkdir -p /opt/casp/module/linux2_optimized/apache_[version]/eapi
  # cd /opt/casp/module/source/build/
  # apxs -c mod_casp2.c
  # cp mod_casp2.so /opt/casp/module/linux2_optimized/apache_[version]/eapi
  # ./configure-server

The initial configuration reports:

 -----------------------------------------------------------------------------
| SERVER CONFIGURATION COMPLETE                                               |
|-----------------------------------------------------------------------------|
|  Your server was successfully configured.  Its information is as follows:   |
| Server installed (asp-server-3000):                                         |
|   Associated Web server conf file: /etc/httpd/conf/httpd.conf               |
|   Associated Web server port: 80                                            |
|   Location: /opt/casp/asp-server-3000                                       |
|   Port: 3000                                                                |
|   Samples: Enabled.                                                         |
|   Documentation: Enabled.                                                   |
|   Automatic ASP start on system boot: Enabled.                              |
|   ASP started: Yes.                                                         |
|   ASP start script: /opt/casp/asp-server-3000/startcaspd                    |
|   ASP stop script: /opt/casp/asp-server-3000/stopcaspd                      |
|   ASP general control script: /opt/casp/asp-server-3000/caspctrl            |
|   Samples URL: http://yggdrasill.thenewpush.com:80/caspsamp                 |
|                                                                             |
 -----------------------------------------------------------------------------

Do you have an authentication routine, like htpasswd to protect web pages?

Authentication in Apache is done through htaccess, either from the configuration file or from the .htaccess file in a given directory. Note that only full directories can be easily protected with this method.
Here is how: (first log in to the shell, as this method only works if
you have shell access)

  • $ cd …/html/protected_dir
  • $ cat > .htaccess
  • AuthType Basic
  • Authname “Protected KLC directory”
  • AuthUserFile ../../control/htpasswd
  • AuthGroupFile /dev/null
  • Require valid-user
  • +d
  • $ htpasswd -c ../../control/htpasswd user_name
  • [give passwd]

After the file is created for the first time, to
add more users:

$ htpasswd ../../control/htpasswd user_name

There are also more sophisticated authentication schemes available, that allow database-driven authentication. Please contact us for more information about those solutions.