Setting up Thawte SSL 123 on nginx

I recently had to setup a new Thawte SSL 123 SSL certificate on a clients webserver that was running nginx, but was having problems with the certificate being valid. The problem was when visiting the website, the browser was reporting it as an unknown issuer. After trying a few different methods including trying to use the ssl_client_certificate directive which didn’t work (not sure why), the solution was the following:

  1. Download your client certificate from thawte
  2. Download the primary and secondary intermediate CAs (Apache version has both certificates in the one file)
  3. Combine the 3 certificates into one file, with your certificate first, then the primary and secondary intermediate certificates.
  4. Add: ssl_verify_depth 3; to your configuration file
  5. Restart nginx

So in the end, your nginx configuration file should look like the following:

ssl_certificate         /path/to/certificate.bundle.cert;
ssl_certificate_key     /path/to/private.key;
ssl_verify_depth 3;

Now your browser should say that the certificate was issues by Thawte DV SSL CA. You can test your SSL has been setup correctly by visiting https://www.wormly.com/test_ssl. This method should also work when setting up any intermediate CAs, but just change the ssl_verify_depth to the number of certificates you are installing.

PHP Performance Tip

To improve the performance of your PHP application, you should work with object properties directly, rather than writing naive settings and getters. If you need getter/setters, you can use the __get and __set magic methods.

I have performed a quick test with the following script (base code is from google performance tips) to show the performance savings.

php -d implicit_flush=off -r ‘class dog { public $name = “”;} $rover = new dog(); for ($x=0; $x<10; $x++) { $t = microtime(true); for ($i=0; $i<1000000; $i++) { $rover->name = “rover”; $n = $rover->name;} echo microtime(true) – $t;echo “\n”;}’
0.27138209342957
0.27215003967285
0.27119302749634
0.27127695083618
0.27089595794678
0.27323412895203
0.27595901489258
0.27139592170715
0.27534413337708
0.27470207214355

php -d implicit_flush=off -r ‘class dog {public $name = “”;public function setName($name) {$this->name = $name; }public function getName() {return $this->name; } }$rover = new dog();for ($x=0; $x<10; $x++) { $t = microtime(true);for ($i=0; $i<1000000; $i++) { $rover->setName(“rover”);$n = $rover->getName();}echo microtime(true) – $t;echo “\n”;}’
0.88418102264404
0.90805292129517
0.88095903396606
0.9102931022644
0.88606786727905
0.91241002082825
0.88503313064575
0.90973210334778
0.87963604927063
0.91335105895996

php -d implicit_flush=off -r ‘class dog {public $name = “”;public function __set($key, $value) {$this->$key = $value;}public function __get($key) {return $this->$key;}}$rover = new dog(); for ($x=0; $x<10; $x++) { $t = microtime(true); for ($i=0; $i<1000000; $i++) { $rover->name = “rover”; $n = $rover->name;} echo microtime(true) – $t;echo “\n”;}’
0.27974605560303
0.28078198432922
0.27995705604553
0.280522108078
0.27998900413513
0.28067207336426
0.27970504760742
0.28028988838196
0.27951693534851
0.28037190437317

TMS (Temporary Mail Server)

TMS is a temporary mail server written in python. What does it do? Well TMS will capture any emails sent to the server and will save the message into a database which can be viewed by visiting the web client. The server will never actually send the email to the recipient so TMS is great if you have a web application that is sending emails that you want to see the message and/or don’t want the email to reach the recipient.

GitHub Link: https://github.com/bmaynard/TMS/

Screenshots:

Any feedback is appreciated!

Mining passwords from public GitHub repositories

I was on GitHub today, and I had a thought about mining database, account and server passwords of public repositories where the developer has forgotten to remove the password from the source code before pushing to the public repository.

I did a simple test using GitHub’s search using certain keywords eg:

It only takes you to go through about 10 pages of search results (“root password” has over 10,000 results) and you can see a few password’s that look like real. GitHub do have an article about remove sensitive data (http://help.github.com/removing-sensitive-data/) but also has a good statement line saying “Once the commit has been pushed you should consider the data to be compromised. Period.” which is very true but it seems there are alot of developers out there that our committing there passwords. I wonder how many hackers have prowled through GitHub looking for passwords and in result successfully been able to pull of an attack.

However, the best search term is “gmail password” (http://github.com/search?type=Code&language=&q=gmail+password&repo=&langOverride=&x=0&y=0&start_value=1) which as you can see, the first result looks like a real gmail password. I haven’t tested any of these passwords but I’m sure there is plenty of real passwords that developers have committed.

So remember, DON’T COMMIT YOUR PASSWORDS!

iniReader – Simple C++ configuration file parser

I have created a very simple C++ class that will parse a configuration file and return the value of the request key. You can get the code from http://github.com/bmaynard/iniReader.

I created this class for my CPUHog application (http://github.com/bmaynard/CPUHog) which records CPU and memory usage of applications running so you can find out which processes where hogging your CPU time.

Please feel free to leave feedback if you have any suggestions or problems. I do plan on make the class more powerful as its very simple at the moment.

**Update: I have made a few updates to the library including:

  • Changed getOption and getOptionChar to getOptionToString and getOptionToChar
  • Added getOptionToInt
  • Added cleanupIniReader which will empty the results from the parsed configuration file