This Tuesday! Learn key insights about modern cyber protection services & gain practical strategies to skyrocket business:
- What it takes to build a cloud service portfolio
- How to determine which services will help your unique business grow
- Various use-cases and examples
Can’t verify SSL peers
I have been running a script which uses a Google docs spreadsheet to update the webpage daily. Every day that Google updates, my data disappears and I have to re-upload the text file again. This script has been working fine for 2 years. The text file gets replaced with the following error message:
I am none the wiser. I don't understand what I am supposed to do. I downloaded the file but then what? Can you please step me through this. I am sure it is easy if you know what you're doing!
File does not exist: Can’t verify SSL peers without knowning which Certificate Authorities to trustI sent an email to the author of the script and he says it is not his script which is at fault and pointed me to this page: http://sysops.ie/blog/2011/03/21/cant-verify-ssl-peers-without-knowning-which-certificate-authorities-to-trust/
This problem can be fixed by either setting the PERL_LWP_SSL_CA_FILE envirionment variable or by installing the Mozilla::CA module.
To disable verification of SSL peers set the PERL_LWP_SSL_VERIFY_HOSTNAME envirionment variable to 0. If you do this you can’t be sure that you communicate with the expected peer.
I am none the wiser. I don't understand what I am supposed to do. I downloaded the file but then what? Can you please step me through this. I am sure it is easy if you know what you're doing!
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
with SSL there are two things at work:
1) are you talking to the right counter party (validation of endpoints)
2) is the connection confidential... (encryption is used)
@2) the key for this connection is determined during 1
@1) during the first phase certificates are exchanged, certificates describe aspects of the endpoint..
For a user mostly an email address, for a server mostly a username...
A certificate exists of the subject (above description), a private key (mostly protected with a pass phrase) and a public key. If the private key is used to encrypt some thing, then the public key can be used to decrypt it again. (and the other way around).
Using a known thing encrypt it and let the other decrypt it can verify one party, doing it both ways can authenticate both partners.
Now the validity of the keys still is not verified... for this we can request a third party to underwrite the validity and sign a certificate. That means a checksum of the certificate is encrypted by the third party
and if we have the public key of that 3rd party we can decrypt and verify the checksum.
Now how to verify that third party... well it can be a chain ... but it needs to be anchored somewhere.
That is what is called a Trusted Third Party. (or CA Certificate Authority) well known brands are:
Verisign, Global Trust. Open Source is CACert.
Those parties are mentioned is a special file/directory (depending on verify library) then the library can accept a certificate that is signed by such a party. (In that directory /file the public key is stored).
1) are you talking to the right counter party (validation of endpoints)
2) is the connection confidential... (encryption is used)
@2) the key for this connection is determined during 1
@1) during the first phase certificates are exchanged, certificates describe aspects of the endpoint..
For a user mostly an email address, for a server mostly a username...
A certificate exists of the subject (above description), a private key (mostly protected with a pass phrase) and a public key. If the private key is used to encrypt some thing, then the public key can be used to decrypt it again. (and the other way around).
Using a known thing encrypt it and let the other decrypt it can verify one party, doing it both ways can authenticate both partners.
Now the validity of the keys still is not verified... for this we can request a third party to underwrite the validity and sign a certificate. That means a checksum of the certificate is encrypted by the third party
and if we have the public key of that 3rd party we can decrypt and verify the checksum.
Now how to verify that third party... well it can be a chain ... but it needs to be anchored somewhere.
That is what is called a Trusted Third Party. (or CA Certificate Authority) well known brands are:
Verisign, Global Trust. Open Source is CACert.
Those parties are mentioned is a special file/directory (depending on verify library) then the library can accept a certificate that is signed by such a party. (In that directory /file the public key is stored).
I don 't need the geek talk. I need help interpreting the instructions in the link provided above. The SSL comes from Google Docs. Can I do this myself or do I need to ask the hosting company to sort it?
Alright, I thought about it .... I went on to the server in cPanel and found a Perl button. Then I did a search for Mozilla::CA and it came up with an install button. So I installed it.
Then it came up with a comment:
I don't know whether I needed to do that or not. I won't know for another day if the script calls the spreadsheet in from Google Docs properly or not.
Then it came up with a comment:
Using Your Perl Module(s)So I have added that at the bottom of the cgi script (although the author of the script said his script was faultless).
You will need to add /home/kidspart/perl to the include path.
You can do this by adding the following code to your script:
BEGIN {
my $base_module_dir = (-d '/home/kidspart/perl' ? '/home/kidspart/perl' : ( getpwuid($>) )[7] . '/perl/');
unshift @INC, map { $base_module_dir . $_ } @INC;
}
I don't know whether I needed to do that or not. I won't know for another day if the script calls the spreadsheet in from Google Docs properly or not.
ok this looks like it was the right move as you cannot set a commandline environment variable.
(You can set some variables using a BEGIN { ... }" statement though.
Appearantly when your Service Provider updates it's cpanel software something get disrupted at the backend and this message is shown.
The script can be faultless, if it used in a different than anticipated/designed for environment it needs adjustment. The script appearantly uses LWP (as can be seen from the mentioned environment variables) LWP changed from an accept anything mode to an really do checkout certificates mode.
That could cause old configurations to fail. That does count as an unanticipated move, btw the old LWP more or less functioned as a door lock that didn't need a specific key, anything could work screwdriver, other keys as long as it was a flat.
To function using cPanel, the module appearently can reverted to the old behaviour or better support checking using the Mozilla::CA environment, that in turn requires that it gets activated hence the code that needs to be run at perl startup "BEGIN { ... }"
The real first question then is: What kind of certificate are you using to access the site?
(You created it your self, or you bought a certificate.)
Both need to be signed by some Certificate Authority (CA) to work. If you created a private CA then you need your CA's certificate by the ISP (might be hard) or if you bought one (from Verisign, global trust etc.) then it should have worked by now.
In the first case you might be better of by turning off the verification (accepting the blank keys again).
(You can set some variables using a BEGIN { ... }" statement though.
Appearantly when your Service Provider updates it's cpanel software something get disrupted at the backend and this message is shown.
The script can be faultless, if it used in a different than anticipated/designed for environment it needs adjustment. The script appearantly uses LWP (as can be seen from the mentioned environment variables) LWP changed from an accept anything mode to an really do checkout certificates mode.
That could cause old configurations to fail. That does count as an unanticipated move, btw the old LWP more or less functioned as a door lock that didn't need a specific key, anything could work screwdriver, other keys as long as it was a flat.
To function using cPanel, the module appearently can reverted to the old behaviour or better support checking using the Mozilla::CA environment, that in turn requires that it gets activated hence the code that needs to be run at perl startup "BEGIN { ... }"
The real first question then is: What kind of certificate are you using to access the site?
(You created it your self, or you bought a certificate.)
Both need to be signed by some Certificate Authority (CA) to work. If you created a private CA then you need your CA's certificate by the ISP (might be hard) or if you bought one (from Verisign, global trust etc.) then it should have worked by now.
In the first case you might be better of by turning off the verification (accepting the blank keys again).
I didn't buy a certificate.
This is how it works: I go into Google docs and put in my spreadsheet. I publish it. I save it as a web page. I copy the link provided which looks like 'https://spreadsheets.google.com/spreadsheet/pub?hl=en&hl=en&key=0Aqlv6gjEkxORd0YmtLMUdRdnJ4bkt2HZUmR2dVE&single=true&gid=0&output=txt' and paste into the line which starts my $google_url_to_spreadsheet
I save the script and upload it to the cgi-bin.
Now, tell me why I need a certificate? Is it because of 'https://spreadsheets.google ?
This is how it works: I go into Google docs and put in my spreadsheet. I publish it. I save it as a web page. I copy the link provided which looks like 'https://spreadsheets.google.com/spreadsheet/pub?hl=en&hl=en&key=0Aqlv6gjEkxORd0YmtLMUdRdnJ4bkt2HZUmR2dVE&single=true&gid=0&output=txt' and paste into the line which starts my $google_url_to_spreadsheet
I save the script and upload it to the cgi-bin.
Now, tell me why I need a certificate? Is it because of 'https://spreadsheets.google ?
Well HTTPS does use SSL and that does use certificates.
So yes it seems related, although i don't know how because i don't know the code in the module...
You can get the previous behaviour back by setting up the code with:
BEGIN {
$ENV{'PERL_LWP_SSL_VERIFY_
};
Now it will not verify the spreadsheets.google.com certificate. (That might be less secure, but in the past you appearantly found it acceptable.
So yes it seems related, although i don't know how because i don't know the code in the module...
You can get the previous behaviour back by setting up the code with:
BEGIN {
$ENV{'PERL_LWP_SSL_VERIFY_
};
Now it will not verify the spreadsheets.google.com certificate. (That might be less secure, but in the past you appearantly found it acceptable.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial