Racker Hacker

When you create a CSR and private key to obtain an SSL certificate, the private key has some internal data called a modulus. This is integral to the security of your SSL encryption, but for this specific post, we will focus on one specific aspect.

If your private key and certificate do not contain the same modulus, then Apache will sometimes refuse to start or it may not respond properly to SSL requests. You can check the modulus of your private key and SSL certificate with these commands:

# openssl rsa -noout -modulus -in server.key | openssl md5
# openssl x509 -noout -modulus -in server.crt | openssl md5

If the MD5 checksums match, then the certificate and key will work together. However, if they are different, then you cannot use them together. Generally, this means that you used the wrong CSR (that corresponded to some other private key) when you obtained/created your SSL certificate.

When you find yourself in a pinch, and you don’t know the limits of a certain Red Hat Enterprise Linux version, you can find this information in one place. Whether you want to know RHEL’s CPU or memory limitations, you can find them here:

http://www.redhat.com/rhel/compare/

I hear a lot of complaints about Plesk’s backup routines and how they can bring a server to its knees. You can reduce the load (except for mysqldumps) by renicing pleskbackup. If you want something really handy, use this Perl scriptlet that I wrote:

#!/usr/bin/perl
@domains = `ls /var/www/vhosts/ | egrep -v '^default\$|^chroot\$'`;
$today = `date +%m%d%y`;
foreach $domain (@domains) {
chomp($domain);
$cmd = "nice -n 19 /usr/local/psa/bin/pleskbackup -vv domains $domain --skip-logs - | ssh someuser\@somehost -i /home/username/.ssh/id_rsa \"dd of=/home/username/pleskbackups/$domain-$today.dump\"";
`$cmd`;
}

It will transmit your backups to another server via SSH, and it will reduce the priority to the lowest available. This combination will reduce CPU usage and disk I/O throughout the backup.

If you find yourself in a pinch and you need a temporary fix when your primary IP is blacklisted, use the following iptables rule:

/sbin/iptables -t nat -A POSTROUTING -p tcp --dport 25 -j SNAT --to-source [desired outgoing ip]

Keep in mind, however, that you will need to adjust any applicable SPF records for your domains since your e-mail will appear to be leaving via one of the secondary IP’s on your server. Also, remember that this is only a temporary fix - you should find out why you were blacklisted and eliminate that problem as soon as possible.

Should you find yourself in the situation where you’ve forgotten the Urchin admin password, don’t worry. It’s easily reset with the following command:

cd util ./uconf-driver action=set_parameter table=user name="(admin)" ct_password=urchin

This will set the password to ‘urchin’, and then you can log into Urchin’s web interface and change it to a secure password. The credit for this fix goes to Urchin’s site.

One question I hear quite often is “how do I add IP aliases in FreeBSD?” It’s not terribly intuitive, but you can follow these steps:

Example:
Server’s primary IP: 192.168.1.5
Additional IP’s to add: 192.168.1.10, 192.168.1.15, and 192.168.1.20

Boot-time configuration:
Add it to /etc/rc.conf first (so you don’t forget). In this example, we have a Realtek card called rl0:
ifconfig_rl0="inet 192.168.1.5 netmask 255.255.255.0"
ifconfig_rl0_alias0="inet 192.168.1.10 netmask 255.255.255.0"
ifconfig_rl0_alias1="inet 192.168.1.15 netmask 255.255.255.0"
ifconfig_rl0_alias2="inet 192.168.1.20 netmask 255.255.255.0"

UBER-IMPORTANT NOTE: Start with the number 0 (zero) any time that you make IP alias configurations in /etc/rc.conf.
This is BAD form:

ifconfig_rl0="inet 192.168.1.5 netmask 255.255.255.0"
ifconfig_rl0_alias1="inet 192.168.1.10 netmask 255.255.255.0"
ifconfig_rl0_alias2="inet 192.168.1.15 netmask 255.255.255.0"
ifconfig_rl0_alias3="inet 192.168.1.20 netmask 255.255.255.0"

If you do it the wrong way (which means starting alias with anything but alias0), only the primary comes up. Keep that in mind.

Bringing up the new IP’s:
You can do things the extraordinarily dangerous way:
# /etc/rc.network restart

Or, you can follow the recommended steps:
# ifconfig rl0 alias 192.168.1.10 netmask 255.255.255.0
# ifconfig rl0 alias 192.168.1.15 netmask 255.255.255.0
# ifconfig rl0 alias 192.168.1.20 netmask 255.255.255.0

Test your work:
Any good system administrator knows to test things once their configured. Make sure to ping your new IP’s from a source on your network and outside your network (if possible/applicable).

Add to /etc/make.conf:

WITHOUT_X11=yes
USE_NONDEFAULT_X11BASE=yes

With portinstall:

# portinstall lighttpd fcgi php5

Without portinstall:

# make -C /usr/ports/www/lighttpd all install clean
# make -C /usr/ports/www/fcgi all install clean
# make -C /usr/ports/lang/php5 all install clean

Add lighttpd_enable="YES" to /etc/rc.conf, and uncomment the usual items in /usr/local/etc/lighttpd.conf to enable fastcgi.

It can be best to upgrade FreeBSD in an offline state, but if you do it online, you can do it like this:

# csup -g -L 2 -h cvsup5.us.freebsd.org /usr/share/examples/cvsup/standard-supfile
# cd /usr/src
# make buildworld
# make buildkernel
# make installkernel
# make installworld
# shutdown -r now

Making Java keystores at the same time as you create a CSR and key is pretty easy, but if you have a pre-made private key that you want to throw into a keystore, it can be difficult. However, follow these steps and you’ll ber done quickly!

Save the new certificate to server.crt and the new key to server.key. If intermediate certificates are necessary, then place all of the certificates into a file called cacert.crt. Now, you will have to make a PKCS #12 file:

openssl pkcs12 -export -inkey server.key -in server.crt -name tomcat-domain.com -certfile cacert.crt -out domain.com.p12

To perform the rest of the work, you will need a copy of the KeyTool GUI. In the GUI, make a new keystore in JKS format. Import the PKCS #12 key pair, and save the keystore as a JKS. Upload the keystore to the server and then configure the keystore within Tomcat/JBoss.