I have used the API of hostip.info for long time to resolve IP addresses to country codes or country names. The web service has been hit by some severe downtime lately returning “500 – Internal Server Error” for any calls including both API and website page requests. As of now hostip.info has been down and unreachable for several days in a row, with no signs of coming up in the near future. Perhaps the maintainer is on holiday or something…
I manage several applications depending on this web service so I started searching for an alternative solution to lookup IP addresses. I did not find anything suitable so I decided to launch my own free IP to country lookup API instead.
This new web service can be found at ip2.cc (IP to Country Code) for everyone to use.
Sometimes data needs moving from server to server without FXP support. For this task there is nothing simpler than good old FTP.
What about if you have a large number of subdirectories? As the plain FTP client can not fetch the files recursively shell scripting is usually the solution. But in cases where you do not really know neither the depth of the recursion or the naming convention of the file system structure, an alternative method is needed.
This method is named NcFTP Client. I got to know about it today as I quickly needed to copy several gigabytes of data spread over several subdirectories and NcFTP did its job flawlessly. I did not even have to install it as Fedora 10 already came with it by default.
Today using the version of Pidgin that came with Fedora10 I received the following certificate prompt:
Accept certificate for ows.messenger.msn.com?
The root certificate this one claims to be issued by is unknown to Pidgin.
The majority of cases of unknown certificate issuers are due to the chain of trust breaking down. This break down in the certificate chain is mainly caused by the software in question not including the intermediate certificate authorities certificates. Without these intermediate certificates the software can not verify through the certificate hierarchy up till the root certificate and therefore prompts the user about what to do.
The options I received in the Pidgin prompt were:
View certificate
Accept
Reject
Upon selecting “View certificate” I am presented with the following details:
Common name: ows.messenger.msn.com
Fingerprint (SHA1): a9:9c:2d:ee:4a:d1:c8:7d:a7:c5:c3:05:32:98:5f:ee:57:87:73:8a
Activation date: Tue Jan 29 14:37:21 2008
Expiration date: Wed Jan 28 14:37:21 2009
So far everything looks as it is a bona fide certificate but to verify the identity completely I load the page https://ows.messenger.msn.com/ in Firefox. As expected no certificate warnings were received and I opened the certificate viewer to see its details and confirmed the data matches up with the data received in Pidgin:
Certificate Viewer
I can safely trust this certificate as Firefox has verified through the certificate chain that all intermediate certificates are valid too:
Certificate Chain
This certificate is simply used by Microsoft for the Live Messengeroffline messaging service. Although you normally would trust verified certificates it did happen in the past that certificates were incorrectlyissued to the wrong people. So always be cautious!
