Certificate verification failed for aspmx.l.google.com untrusted issuer Equifax Secure Certificate AuthorityApril 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
postfix/smtp: connect to aspmx.l.google.com[ip6addr]:25: Network is unreachable
postfix/smtp: certificate verification failed for aspmx.l.google.com[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/main.cf was missing the line:
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
Once added, I restarted postfix with:
and all was well in the world.
I had a few problems connecting to a client's VPN. All the settings were correct:
Server Address: vpn.example.com
Account name: mrn
but it would not connect, it always timed out.
publish_entry SCDSet() failed: Success!
publish_entry SCDSet() failed: Success!
pptp_get_router_address 192.168.0.1 from dict 1
PPTP connecting to server 'vpn.example.com' (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.
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
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.
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/00_mk_authorized_keys.sh 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.
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:
- Logged into web site's Cpanel with Firefox.
- Zipped up the public_html folder.
- Downloaded it.
- Created a folder under my web root.
- Unzipped the files into their new home.
- 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).
- 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 com.apple.quarantine 26 -rw-r--r--@ 1 mrn admin 26618 May 19 2015 File02.JPG com.apple.quarantine 26 -rw-r--r--@ 1 mrn admin 54750 Feb 23 2014 File03.JPG com.apple.quarantine 26
We can see that all the files are marked with com.apple.quarantine 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 com.apple.quarantine 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 com.apple.quarantine 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!