Educating the world

Our blog has over 10,000 readers a month

Certificate verification failed for untrusted issuer Equifax Secure Certificate Authority

April 7th, 2016

For better or worse I'm back using Plesk again. I wish someone could invent something that does want Plesk does only better! One thing you can be sure of when I'm using Plesk, is that plenty of "how do I fix abc on Plesk" articles will suddenly appear.

I tried to set up email forwarding on Plesk server but for some reason the mail was going into the inbox and not being forwarded. I checked file /usr/local/psa/var/log/maillog

postfix/smtp[1234]: connect to[ip6addr]:25: Network is unreachable
postfix/smtp[1234]: certificate verification failed for[ip4addr]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

The initial Googling I did led me to think that the problem was related to Plesk not having the correct certificate to create a secure connection to Google's mail servers citing that Google had changed its certificate authority from Thawte Server CA to Equifax Secure Certificate Authority and that Plesk did not have the Equifax certificate installed. However this turned out not to be the case, all the appropriate certificates were in place.

I found an article in the Plesk knowledge base which solved my problem. The postfix configuration file /etc/postfix/ was missing the line:

smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt

Once added, I restarted postfix with:

/etc/init.d/postfix restart

and all was well in the world.

Connecting to VPN via PPTP always reports Operation timed out

January 27th, 2016

I had a few problems connecting to a client's VPN. All the settings were correct:

Configuration: Default
Server Address:
Account name: mrn
Encryption: Automatic

but it would not connect, it always timed out.


publish_entry SCDSet() failed: Success!
publish_entry SCDSet() failed: Success!
pptp_get_router_address from dict 1
PPTP connecting to server '' (x.x.x.x)...
PPTP connect errno = 60 Operation timed out

I came across this forum post that said "it ended up being the router port forwarding stopped for the VPN port", so I checked my Virgin Super Hub router. After logging in go to the "Advanced Settings", "Security", "Firewall" section. I checked "PPTP Pass-Through" to enable forwarding of PPTP traffic, applied the changes and that fixed it.

Glasgow Fright Fest 2016 Programme

January 12th, 2016

Over the years this has become a little FrightFest survivors' guide. The most important part of a film festival is choosing when to eat and when to grab a quick pint. This year the gaps seem to be between 25 and 50 minutes long. Last year we had to eat a 3 course meal in 25 minutes then rush back to our seats! But it looks like we might have a bit longer this year.

If anyone from FrightFest is reading this then next year can we have a shorter (pee only) gap during the morning to build up a longer gap around food time. There are loads of really nice restaurants in Glasgow but we just end up eating KFC, Wok2Walk and junk because there just isn't enough time to go somewhere nice :(

So to help you with your food planning here is a list of the gaps and their films ;)

Thursday 25 February 2016

21:00 - 22:52 (93m / 1h 33m)
UK Première - The Forest

Friday 26 February 2016

13:30 - 15:05 (95m / 1h 35m)
UK Première - The Hexecutioners


15:40 - 17:11 (91m / 1h 31m)
UK Première - Anguish

1h 19m

18:30 - 20:08 (98m / 1h 38m)
World Première - Pandemic


21:00 - 22:27 (87m / 1h 27m)
UK Première - The Mind's Eye


23:15 - 00:41 (86m / 1h 26m)
European Première - Patchwork

Saturday 27 February 2016

10:00 - 11:44 (104m / 1h 44m)
Scottish Preview - The Wave (original title: "Bølgen")


12:10 - 13:39 (89m / 1h 28m)
UK Première - Southbound


14:05 - 16:05 (120m / 2h)
Preview - SPL 2: A Time for Consequences (original title: "Saat po long 2")


16:40 - 18:16 (96m / 1h 36m)
European Première - The Other Side of the Door


19:05 - 20:42 (97m / 1h 37m)
UK Première - Baskin


21:30 - 22:51 (81m / 1h 21m)
UK Première - Martyrs


23:30 - 01:00 (90m / 1h 30m)
UK Première - The Devil's Candy

More information about these films may be found on the official FrightFest web site.

For previous years' film choices take a look at our main Glasgow Fright Fest page.

Allowing users to logging in with keys

December 14th, 2015

I'm doing more and more work with SSH keys so I thought I'd share this little program with you. When I create a development server I set up SSH keys so that I'm not constantly typing in passwords as I copy stuff around. After creating a new virtual machine I copy the public keys from my other machines over to the ~/.ssh folder on the new machine then I run the following program:

cat *.pub > authorized_keys

This scoops up all the public keys into an authorized_keys file, effectively making them active.

I call this program ~/.ssh/ and I place it next to all the uploaded public keys so that I don't forget to run it when I'm uploading my new keys.

Apache Access forbidden with extended mac @ permissions

December 13th, 2015

I came across an interesting file protection problem with my environment. OSX, Firefox and tar are all involved but I can't tell which component is doing it. The problem manifested itself with Access forbidden messages from Apache.

My objective is to download a customer's website and recreate it on our development system. Simple done it a million times, but strangely I ran into all sorts of problems when I tried to do it on my Mac.

Here is what I did:

  1. Logged into web site's Cpanel with Firefox.
  2. Zipped up the public_html folder.
  3. Downloaded it.
  4. Created a folder under my web root.
  5. Unzipped the files into their new home.
  6. Use Firefox (again) to look at the mirrored site. Firebug was reporting that about half the CSS files were not found (404) and all the image files were Access forbidden (403).
  7. Checked the code and the paths and everything is as it should be. It should be working!!

Went into the folder with the broken images and did a listing to see what's what.

total 432
-rw-r--r--@ 1 mrn  admin  24612 May 10  2015 File01.jpg
-rw-r--r--@ 1 mrn  admin  26618 May 19  2015 File02.JPG
-rw-r--r--@ 1 mrn  admin  54750 Feb 23  2014 File03.JPG

Maybe my Access problems were related to the mysterious @ symbol. A bit of Googling says that the @ sign means the file has extended attributes on top of the standard read-write-execute over owner-group-other permissions that we know and love. You can list the extended attributes with ls -l@

total 432
-rw-r--r--@ 1 mrn  admin  24612 May 10  2015 File01.jpg	   26 
-rw-r--r--@ 1 mrn  admin  26618 May 19  2015 File02.JPG	   26 
-rw-r--r--@ 1 mrn  admin  54750 Feb 23  2014 File03.JPG	   26 

We can see that all the files are marked with a quick check and the original zip file was indeed extended:

myhost:images mrn$ ls -l@ ~/Downloads/ec.tgz 
-rw-r--r--@ 1 mrn  staff  2490100 Dec  2 22:38 /Users/mrn/Downloads/compressed-file.tgz	     26 

This could be the cause of the problem so how do we remove it. It looks like the extended tags have been applied to all the files in the archive, which kind of makes sense, but still it's a bit annoying as there weren't any warnings and it seems to present in an inconsistent way. So probably the best thing to do would be to remove the quarantine attribute from the original archive then uncompress it again. Let's give it a go using the clear switch on the extended attributes command:

myhost:images mrn$ ls -l@ ~/Downloads/ec.tgz 
-rw-r--r--@ 1 mrn  staff  2490100 Dec  2 22:38 /Users/mrn/Downloads/ec.tgz	     26 
myhost:images mrn$ xattr -c /Users/mrn/Downloads/ec.tgz
myhost:images mrn$ ls -l@ ~/Downloads/ec.tgz 
-rw-r--r--  1 mrn  staff  2490100 Dec  2 22:38 /Users/mrn/Downloads/ec.tgz

So unzip and reload the page. Still didn't work. Over the next hour I played with copying the images to different folders until they loaded properly. I eventually figured out that everything under the main unzipped folder behaved strangely. Then it dawned on me that the only thing that could do this would be an .htaccess file and sure enough there it was. It contained the following line which matches URLs which end with an image extension and forbids them.

RewriteRule .*\.(jpg|jpeg|gif|png|bmp)$ - [F,NC]

This configuration is in place on the customer's live server. I renamed my mirrored .htaccess to _htaccess, reloaded the page and everything sprang into life. So their server must have been ignoring the .htaccess file, probably because it isn't an Apache web server so it doesn't understand what do do with it.

So the whole thing had nothing to do with permissions or extended attributes and was merely a straight forward under-sight: I should have checked for .htaccess files. It was an honest mistake as almost all web servers run Apache or something that understands .htaccess files! I have at least demonstrated how a system's administrator would go about solving a problem and we have learnt something along the way. Believe me, you get extremely good at tracking down weird problems when you run a large multi-user system and this one only took an hour to find!