I have a process that uses web services via sockets/https. My code is erroring out all of a sudden when using sockets. I'm guessing it's something to do with progress internal certificate manager.
These are the errors that are occurring.
---------------------------
Error
---------------------------
Secure Socket Layer (SSL) failure. error code -54: certificate signature failure: for b0f3e76e.0 in n:\progra~1\oe101c\certs (9318)
---------------------------
Error
---------------------------
Connection failure for host api.constantcontact.com port 443 transport TCP. (9407)
---------------------------
Error
---------------------------
Invalid socket object used in WRITE method. (9178)
I then decided to get the Cert Chain from the site who's service I was using. I ran this command to get this.
openssl s_client -connect api.constantcontact.com:443 -showcerts > certs.out
After getting the certs I extracted each one into it's own file and tiled them cert1.cer, cert2.cer and cert3.cer. I registered them with the certutil and the error was still occurring.
I then converted all three of them using this command.
openssl x509 -in cert1.cer -out cert1.pem -outform PEM
Then tried registering them again and still no solution.
I registered them in proenv this way.
certutil -import cert1.pem
they imported correctly but I am still getting this error. Is there something that I am missing or could this be something entirely different. In the original error the hash b0f3e76e.0 is in fact being generated by the 3rd cert. I attempted to delete the hash in the certs folder and regenerate it. I'm completely clueless at this point. The app has worked for awhile and i remember having this issue in the past but can't remember what fixed it. Seems as though when someone was changing from a virtual drive to a physical drive that progress is installed on this error started popping back up.
Thanks
Sorry I miss understood. YOu can google the b0f3e76e.0 and try to find the rootCA for it. Then copy the contents of it and using certutil -import on it to see if that works for you.
For example:
URL https://alphassl.com.ua/support/root.pem
copy and paste it to notepad. Save it as rootCA.pem
use certutil -import rootCa.pem. This will give you the certificate the ABL program is looking for to hand shake withthe server you are using for ssl socket connection.
Again sorry for misunderstanding.
The server side may have changed the certificate. YOu may want to re-import the certificate from the server using
openssl s_client -connect api.constantcontact.com:443 -showcerts > certs.out
Then after doing the import, see which hash formatted file you are getting the error. You can google it and find the certificate and use certutil -import again for that specific hash formatted certificate.
I had experienced this types of issue before where they all of a suddent change the certificate which can have chain certificates. Also generates from different certificate authority leveling their own company name.
It also could be that the certificate expired. I just looked at the rootCA on the URL I have mentioned, the validity is expired.
Validity
Not Before: Sep 1 12:00:00 1998 GMT
Not After : Jan 28 12:00:00 2014 GMT
You need to find one that has the valid date for expiration.
this solution is in startup.pf in C:\Progress\OpenEdge, edit and add in last line -sslverify 0 ...
example.
-cpinternal ISO8859-1
-cpstream ISO8859-1
-cpcoll Spanish9
-cpcase Basic
-d dmy
-numsep 44
-numdec 46
-sslverify 0
Related
Like many I have received the MSB3325 strong naming error, I am targeting a pfx file and have tried to install the certificate directly to the CSP at the given container. The certificate is installed on the machine I am working on.
I generated the CSR through OpenSSL and received a p7b from a Certificate Authority, which I then converted to pfx with the key used in generating the CSR (I have also tried using online converters from different CAs to ensure I was not messing up the conversion through OpenSSL). I can confirm the pfx certificate contains the same key.
The sn -i cert.pfx VS_KEY_XXXXXXXXXXXXXXXX succeeds in pairing to the container but I get the exact same error and a failed build. I have tried many times to recreate the pfx and delete the container to pair to the new one. Initially I did not sign a password to the certificate (just pressed enter) but I have also tried giving it one, it made no difference.
I am trying to sign a WPF project and so far have been frustratingly unsuccessful.
Am I missing something? Many hours of research and all results come up to use the sn -i command to fix the problem.
Not 100% sure this is a Perl issue, but it seems to be. I have an IPN script that connects with PayPal to verify transactions. It was working fine until yesterday, when I installed LWP::Protocol::https. Since then, it's been failing with the error:
Can't connect to www.paypal.com:443 (certificate verify failed)
LWP::Protocol::https::Socket: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/local/share/perl5/LWP/Protocol/http.pm line 47.
Running GET https://www.paypal.com from bash (which uses LWP) yields the same error message. OTOH, running GET https://www.gmail.com is successful. Running openssl s_client -host paypal.com -port 443 returns (among other things) Verify return code: 0 (ok). curl "https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate" successfully receives a response from PayPal. So it does seem to be Perl-specific.
Module versions:
LWP 6.13
LWP::Protocol::https 6.06
IO::Socket::SSL 2.015
Mozilla::CA 20141217 (note: I've tried the script both using Mozilla::CA and without it... results have been the same)
Please let me know if there are other relevant modules. Perl version is 5.10.1. Server OS is RHEL 6.
Mozilla::CA 20141217 (note: I've tried the script both using Mozilla::CA and without it... results have been the same)
In short:
I don't know what "without it" means for RHEL6 but please try again with Mozilla::CA 20130114 or with the "older ca-bundle" linked from http://curl.haxx.se/docs/caextract.html.
Details:
The certificate chain you get from www.paypal.com
[0] www.paypal.com
[1] Symantec Class 3 EV SSL CA - G2
[2] VeriSign Class 3 Public Primary Certification Authority - G5
The last certificate in the chain is signed by the 1024 certificate
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
Since 1024 bit certificates where removed by Mozilla end of last year you will not find them in the current Mozilla::CA any longer. But browsers don't need the old certificate because the create the trust chain based on certificates [0] and [1] already because they use a built-in certificate instead of the certificate [2] send by the server.
While this newer built-in certificate is also included in Mozilla::CA it will not be used because of a long-standing bug in how OpenSSL validates certificates: it will always try to validate the longest chain and not check if a shorter chain is possible.
For more details about this problem see
the original bug report against OpenSSL from 2012
a more recent description of the problem, which not only affects Perl but also python, ruby, curl, wget... - i.e. everything which uses OpenSSL: https://stackoverflow.com/a/27826829/3081018
The problem can be resolved by using the flag X509_V_FLAG_TRUSTED_FIRST which was introduced with OpenSSL 1.02 (released 4 month ago and probably not in RHEL yet) or by using an even newer and not yet released version of OpenSSL where they finally fixed the problem (see https://rt.openssl.org/Ticket/Display.html?id=3637&user=guest&pass=guest).
The problem can be worked around by having the older 1024 bit CA certificates still available, i.e either using an older Mozilla::CA or CA bundle or using the system CA store which usually includes these older CA. See also:
A current bug report against IO::Socket::SSL to use the X509_V_FLAG_TRUSTED_FIRST by default (if available). This flag gets set with 2.016 (not yet released) but needs a version of Net::SSLeay which exports this flag (not yet released) and OpenSSL 1.02 (not included in RHEL).
A pull request against LWP to use the default CA on the system instead of Mozilla::CA. This would probably save the problem for you too. Note that Debian/Ubuntu have a similar patch included. I don't know about the version of LWP shipped with RHEL.
I have a p12 file. This was generated from a DigiCert p7b.
When I import this into my personal store on one machine (windows server, using certificates mmc) it shows me one chain when I view the path.
Using the same file, I import into my personal store on a different machine (also windows, using certs mmc). On this one I see a different path (and in this case it has an expired hop)
Specifically, two hops above my cert the divergence occurs.
Why does this happen? Is there anything I can do to influence that chain (remember its the same p12 that is creating different paths)?
I should also say, I am no expert in this area. I'm a developer that muddles through these security issues when needed.
I had the same issue. Two different windows 2008 r2 servers, same certificate. After standard OS patching one of the servers was sending only the first layer of certificate trust chain (number 0), so the openssl client was failing with the message:
verify error:num=21:unable to verify the first certificate
No idea what was the root cause. I tried to
reassign certificate in IIS
reimport certificate
restart IIS
with no success. What finally helped to fix the issue was the server reboot...
Closing this out.
I'm still a little foggy on why things were working the way they did but some things made sense.
It seems the .p12 was created from a p7b that included some of the intermediate certs. One of the included intermediates was the bad one. This explains why the chain was bad on one machine.
Still not sure how I was able to see a good chain on different machine but I understand why I saw the bad one. It seems the good chain was the fluke and the bad chain should have been expected (I originally assumed the opposite).
I created a new .p12 without the intermediates. Cleaned up all the bad intermediates that were previously imported from the first .p12 in both service user and local machine stores. All seems to be working as expected now with same valid chain on all machines.
I'm using WWW::Mechanize to load the catalog from our product provider into our database. I run this script every 2 hours everyday and it completes in arround 12 minutes by using around 50 simultaneous threads.
Everything was working perfectly, until this weekend. They put their website offline for a scheduled maintenance and, once they where online again, my script no longer worked. After analyzing things, it comes down to the following code failing:
use strict;
use warnings;
use WWW::Mechanize;
my $mec = WWW::Mechanize->new;
$mec->get('https://www.imstores.com/Ingrammicromx/login/login.aspx');
print $mec->content;
The code dies (after about 60 seconds) with the following message:
Error GETing https://www.imstores.com/Ingrammicromx/login/login.aspx:
Can't connect to www.imstores.com:443 at test.pl line 7.
Now, these are the points that are making me difficult to find the problem:
It's not network-related - if I visit the same URL from any of my browsers, I get the page.
If I try the same code on a remote machine that contains an exact copy of my Perl installation, it works.
If I use Net::SSL before WWW::Mechanize, it takes a very LONG time, but finally gets the page.
If I try any other SSL page, like 'https://www.paypal.com', it works and very fast.
Then again, it was working before their scheduled maintenance.
I'm not sure what else to try. If I switch to the non-SSL version, it works, but I don't want to do that since we automate purchasing operations.
Along with many things that have crossed my mind, thinking about why it works on the remote machine and why I can open the page in my browsers in the local one:
Is it possible to get blocked with my SSL public key? Is that possible? If so, what public key is LWP/Mechanize using for SSL sessions and how can I use a different one?
Some data on my current setup:
OS: Windows 7 Ultimate x64
Perl version: 5.16.3 x64
LWP::UserAgent version: 6.05
WWW::Mechanize version: 1.72
IO::Socket version: 1.34
IO::Socket::SSL version: 1.85
Net::SSL version: 2.85
Crypt::SSLeay version: 0.64
Thanks in advance for any helpful comment.
Here's the actual reason for the problem: You need to use SSLv3 or TLS1 instead of TLS1.2 to connect to that server. This is probably why it worked when you used Net::SSL first; I believe it tries different ciphers in a way that WWW:Mechanize doesn't.
This is how I found it:
I tried connecting from several different servers, and I find that the ones that worked have an older SSL version. I then checked the difference between what ciphers are used in the versions, and tried connecting with different ciphers.
When I connect using TLS1.2, I get:
$ openssl s_client -connect www.imstores.com:443 -tls1_2
CONNECTED(00000003)
write:errno=54
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 322 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
But when I connect with SSLv3 or TLS1, I get:
$ openssl s_client -connect www.imstores.com:443 -tls1
CONNECTED(00000003)
depth=0 /serialNumber=O3gPUAuGGROuHEhlyLaeJfj7SOn6tFTx/C=US/O=www.imstores.com/OU=GT29846307/OU=See www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated - QuickSSL(R) Premium/CN=www.imstores.com
verify error:num=20:unable to get local issuer certificate
[...and so on, including server certificate...]
Exactly how to make WWW:Mechanize use TLS1 or SSLv3 is left as an exercise to the student.
I'm trying to sign an XPI on linux (no gui) using the NSS cert db (cert8.db and key3.db) i copied from another server of mine, on which I can sign XPI's just fine.
On the new box I can sign with a brand new test certificate ok, but when i try to use the old cert db, it complains with:
signtool: PROBLEM signing data (Unknown issuer)
Certutil lists the cert im trying to use with a * and the CA is present in there as well.
Is this cert db transferable between computers like this? Or are there any other files I have to setup?
TIA
Mike
im not sure if this is what you need, but here it is: http://www.mercille.org/snippets/xpiSigning.php
If the certificate chain has an intermediate CA that also needs to be there.
NSS is rather picky when it comes to the chain and also needs the certs to have been marked as trusted.