Archive for the ‘Security’ category

SSL: Untrusted Connection in Firefox

June 8th, 2010

This is primarily for PositiveSSL Certificates

If you’ve ever received an “Untrusted Connection” from Firefox, specifically with the error “Error code: sec_error_unknown_issuer”, then one possible fix is to append your issuer’s own certificates to yours.

For example if you have a domain.crt file, then download the PositiveSSL CA Bundle, once downloaded append it’s content to the end of your own certificate and then restart the webserver.

For example if your certificate looks something like this:

—–BEGIN CERTIFICATE—–
AwEAAaOCAcowggHGMB8GA1UdIwQYMBaAFLjKEekGMXnbw5TG6BkqvLs1FjGkMB0G
A1UdDgQWBBTH5gLAPZa1SyJ9NU/bIB2Ci+q0YjAOBgNVHQ8BAf8EBAMCBaAwDAYD
VR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwRgYDVR0g
BD8wPTA7BgsrBgEEAbIxAQICBzAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnBv
c2l0aXZlc3NsLmNvbS9DUFMwaQYDVR0fBGIwYDAvoC2gK4YpaHR0cDovL2NybC5j
b21vZG9jYS5jb20vUG9zaXRpdmVTU0xDQS5jcmwwLaAroCmGJ2h0dHA6Ly9jcmwu
MIIEkjCCA3qgAwIBAgIQPV6rece1lR6IHiQhSIJSZTANBgkqhkiG9w0BAQUFADBx
MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDb21vZG8gQ0EgTGltaXRlZDEXMBUGA1UE
AxMOUG9zaXRpdmVTU0wgQ0EwHhcNMTAwNjA4MDAwMDAwWhcNMTEwNjA4MjM1OTU5
C1Bvc2l0aXZlU1NMMRQwEgYDVQQDEwtrYmVlemllLm5ldDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAtjW+zyGQTevv6oo/Y8Oh1vSq4Xl0wkP4XJBA7Gf6qXjh
AxIh/+KBC2LjOI5N2drQvnFFSFX9D+t35GRpiXtzZauqJYKSFuR2a3Ie2gZyVTUC
Y29tb2RvLm5ldC9Qb3NpdGl2ZVNTTENBLmNybDBrBggrBgEFBQcBAQRfMF0wNQYI
KwYBBQUHMAKGKWh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL1Bvc2l0aXZlU1NMQ0Eu
Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJwYDVR0R
BCAwHoILa2JlZXppZS5uZXSCD3d3dy5rYmVlemllLm5ldDANBgkqhkiG9w0BAQUF
AAOCAQEAW/M7T5oUvp+JB4XNQpxHzf5e/0MN0x/+nUBdWPbY1hW58ccUEqyh/g82
PSvK7bYAsVrJ7mkt3h53L4941SjhcMftGDGov8o3Awfs8CLfTBymtbUKVd/h41m9
BGH9Y9jkdw+PSnIRldg84KjVukfzdw==
—–END CERTIFICATE—–

It would become something like this:

—–BEGIN CERTIFICATE—–
AwEAAaOCAcowggHGMB8GA1UdIwQYMBaAFLjKEekGMXnbw5TG6BkqvLs1FjGkMB0G
A1UdDgQWBBTH5gLAPZa1SyJ9NU/bIB2Ci+q0YjAOBgNVHQ8BAf8EBAMCBaAwDAYD
VR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwRgYDVR0g
BD8wPTA7BgsrBgEEAbIxAQICBzAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnBv
c2l0aXZlc3NsLmNvbS9DUFMwaQYDVR0fBGIwYDAvoC2gK4YpaHR0cDovL2NybC5j
b21vZG9jYS5jb20vUG9zaXRpdmVTU0xDQS5jcmwwLaAroCmGJ2h0dHA6Ly9jcmwu
MIIEkjCCA3qgAwIBAgIQPV6rece1lR6IHiQhSIJSZTANBgkqhkiG9w0BAQUFADBx
MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDb21vZG8gQ0EgTGltaXRlZDEXMBUGA1UE
AxMOUG9zaXRpdmVTU0wgQ0EwHhcNMTAwNjA4MDAwMDAwWhcNMTEwNjA4MjM1OTU5
C1Bvc2l0aXZlU1NMMRQwEgYDVQQDEwtrYmVlemllLm5ldDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAtjW+zyGQTevv6oo/Y8Oh1vSq4Xl0wkP4XJBA7Gf6qXjh
AxIh/+KBC2LjOI5N2drQvnFFSFX9D+t35GRpiXtzZauqJYKSFuR2a3Ie2gZyVTUC
Y29tb2RvLm5ldC9Qb3NpdGl2ZVNTTENBLmNybDBrBggrBgEFBQcBAQRfMF0wNQYI
KwYBBQUHMAKGKWh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL1Bvc2l0aXZlU1NMQ0Eu
Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJwYDVR0R
BCAwHoILa2JlZXppZS5uZXSCD3d3dy5rYmVlemllLm5ldDANBgkqhkiG9w0BAQUF
AAOCAQEAW/M7T5oUvp+JB4XNQpxHzf5e/0MN0x/+nUBdWPbY1hW58ccUEqyh/g82
PSvK7bYAsVrJ7mkt3h53L4941SjhcMftGDGov8o3Awfs8CLfTBymtbUKVd/h41m9
BGH9Y9jkdw+PSnIRldg84KjVukfzdw==
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
MIIFAzCCA+ugAwIBAgIQTM1KmltFEyGMz5AviytRcTANBgkqhkiG9w0BAQUFADCB
lzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2Ug
Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho
dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3Qt
SGFyZHdhcmUwHhcNMDYwOTE4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjBxMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT
YWxmb3JkMRowGAYDVQQKExFDb21vZG8gQ0EgTGltaXRlZDEXMBUGA1UEAxMOUG9z
aXRpdmVTU0wgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9T3lY
IpPJKD5SEQAvwKkgitctVR4Q57h/4oYqpOxe6eSSWJZUDfMXukGeFZFV78LuACAY
RYMm3yDMPbOhEzEKIVx5g3mrJBVcVvC0lZih2tIb6ha1y7ewwVP5pEba8C4kuGKe
joteK1qWoOpQ6Yj7KCpNmpxIT4O2h65Pxci12f2+P9GnncYsEw3AAcezcPOPabuw
PBDf6wkAhD9u7/zjLbTHXRHM9/Lx9uLjAH4SDt6NfQDKOj32cuh5JaYIFveriP9W
XgkXwFqCBWI0KyhIMpfQhAysExjbnmbHqhSLEWlN8QnTul2piDdi2L8Dm53X5gV+
wmpSqo0HgOqODvMdAgMBAAGjggFuMIIBajAfBgNVHSMEGDAWgBShcl8mGyiYQ5Vd
BzfVhZadS9LDRTAdBgNVHQ4EFgQUuMoR6QYxedvDlMboGSq8uzUWMaQwDgYDVR0P
AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwewYDVR0fBHQwcjA4oDagNIYy
aHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1IYXJkd2FyZS5j
cmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUhh
cmR3YXJlLmNybDCBhgYIKwYBBQUHAQEEejB4MDsGCCsGAQUFBzAChi9odHRwOi8v
Y3J0LmNvbW9kb2NhLmNvbS9VVE5BZGRUcnVzdFNlcnZlckNBLmNydDA5BggrBgEF
BQcwAoYtaHR0cDovL2NydC5jb21vZG8ubmV0L1VUTkFkZFRydXN0U2VydmVyQ0Eu
Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQAdtOf5GEhd7fpawx3jt++GFclsE0kWDTGM
MVzn2odkjq8SFqRaLZIaOz4hZaoXw5V+QBz9FGkGGM2sMexq8RaeiSY9WyGN6Oj5
qz2qPMuZ8oZfiFMVBRflqNKFp05Jfdbdx4/OiL9lBeAUtTF37r0qhujop2ot2mUZ
jGfibfZKhWaDtjJNn0IjF9dFQWp2BNStuY9u3MI+6VHyntjzf/tQKvCL/W8NIjYu
zg5G8t6P2jt9HpOs/PQyKw+rAR+lQI/jJJkfXbKqDLnioeeSDJBLU30fKO5WPa8Y
Z0nf1R7CqJgrTEeDgUwuRMLvyGPui3tbMfYmYb95HLCpTqnJUHvi
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
MIIEhjCCA26gAwIBAgIQUkIGSk83/kNpSHqWZ/9dJzANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEwNDgzOFow
gZcxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl
IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY
aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMR8wHQYDVQQDExZVVE4tVVNFUkZpcnN0
LUhhcmR3YXJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsffDOD+0
qH/POYJRZ9Btn9L/WPPnnyvsDYlUmbk4mRb34CF5SMK7YXQSlh08anLVPBBnOjnt
KxPNZuuVCTOkbJex6MbswXV5nEZejavQav25KlUXEFSzGfCa9vGxXbanbfvgcRdr
ooj7AN/+GjF3DJoBerEy4ysBBzhuw6VeI7xFm3tQwckwj9vlK3rTW/szQB6g1ZgX
vIuHw4nTXaCOsqqq9o5piAbF+okh8widaS4JM5spDUYPjMxJNLBpUb35Bs1orWZM
vD6sYb0KiA7I3z3ufARMnQpea5HW7sftKI2rTYeJc9BupNAeFosU4XZEA39jrOTN
SZzFkvSrMqFIWwIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8D
veAky1QaMB0GA1UdDgQWBBShcl8mGyiYQ5VdBzfVhZadS9LDRTAOBgNVHQ8BAf8E
BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0f
BHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20vQWRkVHJ1c3RFeHRl
cm5hbENBUm9vdC5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRU
cnVzdEV4dGVybmFsQ0FSb290LmNybDANBgkqhkiG9w0BAQUFAAOCAQEAYGQ5WaJD
ZS79+R/WrjO76FMTxIjuIxpszthkWVNTkOg239T88055L9XmjwzvKkFtcb2beDgj
03BLhgz9EqciYhLYzOBR7y3lzQxFoura7X7s9zKa5wU1Xm7CLGhonf+M8cpVh8Qv
sUAG3IQiXG2zzdGbGgozKGYWDL0zwvYH8eOheZTg+NDQ099Shj+p4ckdPoaEsdtf
7uRJQ8E5fc8vlqd1XX5nZ4TlWSBAvzcivwdDtDDhQ4rNA11tuSnZhKf1YmOEhtY3
vm9nu/9iVzmdDE2yKmE9HZzvmncgoC/uGnKdsJ2/eBMnBwpgEZP1Dy7J72skg/6b
kLRLaIHQwvrgPw==
—–END CERTIFICATE—–

Upon restarting it should cause newer strict browsers to lookup and identify the issuer correctly.

How to Steal an Android Market App

April 10th, 2010

One of the biggest fear plaguing any freelance application developer is piracy. All their hours and hours of work to bring you the next useful little app that they hope you’ll enjoy. So why shouldn’t they be compensated for their hard work. Sometimes however this fear can hurt a new platform more than it can help. That is why in this article I will show you how easy it is to steal even a protected android market app.

Step One – Rooting your phone

Rooting your android device is similar to jailbreaking your iPod Touch or iPhone. Basically gives you the ability to perform tasks normally reserved only for the ‘root’ user of the device. The method of rooting vary greatly depending on the device. I personally own a T-Mobile MyTouch 3G Limited Edition (fender) which is identical to the new T-Mobile MyTouch 3G v1.2 with the headphone jack on top, the only difference is design, and the size of the miniSDHC card that comes with it. I rooted my phone by following the instructions found in this XDA Developer forum thread. If you have one of the older MyTouches you can easily find how-to guides on the same forum corresponding to the Magic 32A and 32B.

Warning: Like most things in gadget life, performing an action such as above not only has the possibility of voiding your warranty, but can also brick your device, that is to say it’ll be no better than a brick that won’t even turn on. So proceed at caution. It is very important to not only carefully read any instructions (such as provided by the link above) but also to verify that your device actually matches the instruction’s requirements. Most people who do this tend to have no problems, but those who fail to actually follow instructions have a very good chance at flashing the wrong recovery or radio image.

Once you are rooted, you can download the Android Software Developer’s Kit, or find the ConnectBot App in the market place. Sometimes protected applications (like the free Paypal app) may not show up after rooting, usually installing the Market Enabler fixes this.

Step Two – Purchase

For this demonstration to work we need to make a purchase. For this article I’ve decided to purchase Retro Defense by Larva Labs. I’ve always enjoyed the games from Larva Labs.

Ok, so we have purchased the game, now what?

Step Three – Back it up

With your rooted phone you can now either open up ConnectBot, or in your terminal run “adb shell” (from the SDK).

Once you are in the terminal as root (you may have to type su if you see $ instead of # to elevate yourself as the root user), you can then follow the following commands, to make a directory and copy the game to that directory.

# cd /sdcard
# mkdir /backapk
# cd /data/app
# ls (you'll see a screen showing you the file content, find the file you want)
# cp com.larvalabs.retrodefense.apk /sdcard/backapk

You may be prompted by SUuser application to allow Connectbot root access (if you used adb shell instead you won’t see this prompt)




At this point all you have done was make a backup of your app/game onto the SD card. Protected application usually exist in /data/app-private as an apk (leaving a small .zip in the /app location)

Configuring SNI with NginX

December 28th, 2009

Traditionally for every SSL certificate issued, you needed a separate and unique IP address. However if you compile OpenSSL and NginX with TLS SNI (Server Name Identification) support you can install multiple SSL certificates without having to bind a domain name to a specific IP address or require each certificate to have its own unique IP.

First thing we need to do is actually compile OpenSSL with TLS SNI support. We’ll start by downloading the latest source and unpacking it into a temporary directory. For this article I keep all sources in ~/src.

$ cd ~/src
$ wget http://www.openssl.org/source/openssl-0.9.8l.tar.gz
$ tar zxvf ./openssl-0.9.8l.tar.gz
$ cd ./openssl-0.9.8l

We’ll then configure with TLS support:

$ ./config enable-tlsext
$ make
$ make install
$ cd ..

Assuming the Nginx source also resides in ~/src you can add the following option to your configure statement when compiling Nginx from source (you can also instead use an absolute path such as /root/src/openssl-0.9.8l/).

--with-openssl=../openssl-0.9.8l/

Once compiled and installed you can check to see if TLS SNI is enabled:

[root@host src]# nginx -V
nginx version: nginx/0.8.31
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-46)
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx 
--add-module=/usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/ext/nginx 
--pid-path=/usr/local/nginx/logs/nginx.pid --sbin-path=/usr/local/sbin/nginx 
--with-md5=/usr/lib --with-sha1=/usr/lib --with-http_ssl_module 
--with-http_realip_module --with-http_gzip_static_module 
--with-openssl=/root/src/openssl-0.9.8l/

From there you will no longer be required to have an SSL enabled server block on it’s own unique IP. You won’t even have to have the block listening to a specific IP either since now OpenSSL will handle the certificate validation based on the server name.

Cloaking and Faking the Referrer

November 23rd, 2009

Cloaking the Referrer

This portion is the more useful portion out of the two if you are trying to drive traffic from a site that is not exactly ‘kosher’ (ie: blackhat). You’ll need a whitehat domain and landing page to make this method effective.

For this article I wrote a simple php script, it may take a second to wrap your head around. I’m not using short tags here because as of PHP 5.3 they are no longer supported by default.

At the very least there is three components to Cloaking the referrer:

  • The Blackhat Domain
  • The Whitehat Domain
  • The ‘Fake’ Landing Page

The first part is simply direct linking from the blackhat domain to the whitehat one.

The second part is the PHP code below, for my example I’m treating it as the base file on the domain (index.php) which will start the redirect process when the blackhat domain is detected as the referrer.

<?php
/* Setup your sites here, blackhat, whitehat and advertiser */
$bh = "http://blackhat.kbeezie.com/";
$wh = "http://whitehat.kbeezie.com/";
$ad = "http://advertiser.kbeezie.com/";
 
/* Grabs the querystring, referer, and initialized some variables */
$pg = (isset($_SERVER['QUERY_STRING']))?$_SERVER['QUERY_STRING']:'';
$rf = (isset($_SERVER['HTTP_REFERER']))?$_SERVER['HTTP_REFERER']:'';
$meta=$js=$ie=$lp="";
 
/* if the referrer is the blackhat domain start a meta redirect
and assign a temporary cookie for 5 seconds */
if(substr($rf, 0, strlen($bh)) == $bh) { 
	$meta = $wh.'?r'; 
	setcookie("r", "1", time()+5); 
}
/* The first meta refresh has completed, and 
we're checking for the 'r' cookie, if set
set a meta refresh back to the domain and set
a new 'rr' cookie while killing the old 'r' one. */
elseif(isset($_COOKIE['r'])) {
	$meta = $wh; 
	setcookie("r", "", time()-5); 
	setcookie("rr", "1", time()+5);
}
/* If we're back to the base of the domain, and the 'rr' cookie is set
then we need to prepare for the final redirect to the advertiser
using javascript */
elseif(($_SERVER['REQUEST_URI'] == '/') && (isset($_COOKIE['rr'])))
{
	if (isset($_SERVER['HTTP_USER_AGENT']) && (strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE') !== false))
	{
		$js = "document.forms[0].submit();";
		$ie = true; 
	} else {
		$js = 'window.location = "'.$ad.'";';
	}
	setcookie("rr", "", time()-5);
}
 
/* It is much faster to send meta data via the HTTP headers
its also a good way to hide the meta data from the HTML 
source itself */
header("Content-Type: text/html; charset=UTF-8");
if($meta != "") header("refresh: 0;url=".$meta);
if(($meta == "") && ($js == "")) $lp = true;
echo '<?xml version="1.0" encoding="UTF-8"?>'; 
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
	<head profile="http://gmpg.org/xfn/11">
		<title>Whitehat Domain</title>
		<script type="text/javascript" defer="defer">
		<!--
			<?php echo $js; ?>
		//-->
		</script>
	</head>
	<body>
		<?php if($lp === true)
			//Redirect to your lander, or load it here.
			echo "<b>There would be a landing page here if the destination owner attempted to visit the referral url.</b>";
		?>
		<?php if($ie === true) { ?>
			<form action="<?=$ad?>" method="get"></form>
		<? } ?>
		&nbsp;
	</body>
</html>

Some Explanations

You’ll notice the first two redirects are to blank out the referrer using a Double Meta Refresh (DMR). Course with Firefox and Internet Explorer using a quick meta refresh already blanks out the referrer by the time the second page loads, as such why cookies are being used. Safari appears to keep the previous page as the referrer during each zero second refresh, but that configuration wasn’t compatible with all three browsers.

After the DMR has completed, we want to refresh via Javascript. Safari and Firefox will carry the referrer over from the whitehat domain when the window.location method is used, but Internet Explorer will instead blank the referrer. Because of this, we have to resort to using a form submission to force the referrer to be sent.

The result of the above script will cause the advertiser to see http://whitehat.kbeezie.com as the referrer instead of http://blackhat.kbeezie.com. Also any attempt of the advertiser to visit the referring URL will result in the landing page loading, instead of a redirection.

On the next page I’ll show you how to fake a referrer, even if you don’t own that domain.

WordPress Automatic Update with SSH

November 22nd, 2009

If you’re like me, you don’t even want the insecure FTP protocol running on your server, but by default wordpress doesn’t even give you the option of using SSH to automatically upgrade your plugins, or wordpress itself.

I’m using a barebone CentOS server for this site, running on the Nginx webserver. I do not have a FTP server installed, and would very much prefer not to have one. Right now the only way to get into the server is via SSH. Below is a working configuration added to the wp-config.php file.

define('FS_METHOD', 'direct'); // 'ssh' is also an option, but did not work for my setup
define('FTP_BASE', '/opt/local/nginx/html/domain.com/');
define('FTP_CONTENT_DIR', '/opt/local/nginx/html/domain.com/wp-content/');
define('FTP_PLUGIN_DIR ', '/opt/local/nginx/html/domain.com/wp-content/plugins/');
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');
define('FTP_USER', 'username');
define('FTP_HOST', 'your-domain.com:22');

You can generate a public/private key by executing the following:

$ ssh-keygen

It will ask you where you wish to save the key (the default path usually /home/username/.ssh/id_rsa should be fine), followed by a passphrase which you can just leave blank for this purpose, then the location of the public key which is fine at its default location (usually /home/username/.ssh/id_rsa.pub)

You’ll also want to create an authorized key file by copying the public key into authorized_keys. We also need to make sure to set the proper permissions.

$ cd ~/.ssh
$ cp id_rsa.pub authorized_keys
$ cd ~/
$ chmod 755 .ssh
$ chmod 644 .ssh/*

By using the key pair shown in the configuration above you only have to supply the SSH username, otherwise if you don’t want to use key pairs, you can instead provide your SSH password with the following line:

define('FTP_PASS', 'password');

Make sure that the folders where updates (such as plugins) will need to be performed are writable by wordpress. From there when you click “upgrade automatically” it should just simply happen.

Using Namecheap’s Free SSL with Nginx

November 21st, 2009

Most of my domains are registered with Namecheap, and powered by Nginx. The site you are viewing now is one such example. Currently with Namecheap, domain registrations, hosting, transfers and WhoIS protection come with a free PositiveSSL subscription (course even if they eventually stop that special, 9.95/year is still a good price for a PositiveSSL certificate). This section will show you how to generate a certificate request with OpenSSL and how to install the provided certificate into Nginx.

Most hosting providers that allow you to install a SSL certificate will normally be using a Cpanel/WHM setup with the Apache Webserver. In which case SSL installation can be quite and visually straight forward, as its pretty much cut and paste back an forth. While you don’t get this luxery with Nginx, its not that difficult to configure.

What you will need on the server:

A unique IP address. The domain you are getting the certificate for does not have the be the only domain served on the chosen IP address. However Nginx will only serve one certificate per IP. An attempt to install two certificates on the same IP will result in the latter domain serving the previous domain’s certificate.

SSH access. Otherwise known as ‘shell access’, would be required to perform most of the tasks yourself. If you have installed Nginx onto a remote server yourself, then chances are you have shell access. Also if you’re running Nginx you’re not likely using shared hosting, which is normally void of shell access.

OpenSSL In order to actually generate a request and serve the certificate you will need OpenSSL installed. Using a repository such as yum on CentOS you can install this with the package openssl and openssl-devel (depending on the repository the package names could vary).

Nginx webserver configured with SSL. In order for Nginx to serve SSL certificates, Nginx must be built with the option –with-http_ssl_module. To verify you can run nginx -V from the terminal to see all the options your current release was built with. If you installed Nginx from a repository, you may need to see if there exists a SSL variation. KBeezie.com is currently running on Nginx 0.8 and hosted by KnownHost.

Assuming you have all the above in place, we can start by creating private key followed by the CSR file otherwise known as a Certificate Signing Request.