pcomm 5.6: Error code 414
Rex Dieter
Communications Server (TCPIP) via SSL, and it only mysteriously fails with:
error code 414
no idea what that means, can't find it in the help, documentation, ibm's
website, or googling.
Connecting to this same server using qws3270 secure works.
Hints/ideas?
-- Rex
lan...@us.ibm.com
The 414 is an SSL error code which in this case probably
means that the certificate presented by the z/OS tn server
was not in the key database that pcomm is using or the
signer of that server cert was not in pcomm's key database.
If the z/OS server is using a self-signed certificate then
you need to extract the public key info from that certificate
and insert it into the key database on the PC as a 'Signer' cert.
If the z/OS server is using a CA-signed (Certificate Authority)
certificate then you need to get the CA's public root cert and
insert it into the key database on the PC as a 'Signer' cert.
The '... insert ...' part would be done with PCOMM's "Certificate
Management" tool:
Start
Programs
IBM Personal Communications
Utilities
Certificate Management
then you configure the PCOMM session to point to that key database.
The Help / Contents of the Certificate Management Utility is
also a good thing to read at this point.
Later levels of PCOMM help with the 'extract' part with a button
under the Communication / Security Information pull-down on the
3270 session window. But I don't think that button exists on
PCOMM 5.6.
My guess is that qws3270 offered an 'accept this cert' pop-up,
just like many web browsers, and it sucked the public key info
into it's database automatically.
Paul Landay
Rex Dieter
> Rex Dieter wrote:
>> We're trying to use Pcomm v5.6 (and v5.0) to connect to IBM's z/OS
>> Communications Server (TCPIP) via SSL, and it only mysteriously fails
>> with: error code 414
>> no idea what that means, can't find it in the help, documentation, ibm's
>> website, or googling.
>>
>> Connecting to this same server using qws3270 secure works.
>>
>> Hints/ideas?
> The 414 is an SSL error code which in this case probably
> means that the certificate presented by the z/OS tn server
> was not in the key database that pcomm is using or the
> signer of that server cert was not in pcomm's key database.
The cert in question is signed by Verisign (or so I'm told by those admining
the server in question), and Versign is in pcomm's list of CA's already (as
shown by the Cert Manager anyway).
> My guess is that qws3270 offered an 'accept this cert' pop-up,
> just like many web browsers, and it sucked the public key info
> into it's database automatically.
qws3270 secure (supposedly) uses CA authorities too, but uses the
implementation of cert management builtin to windows, not like PComm's
separate-but-equal (re)implementation of the same thing. (:
-- Rex
lan...@us.ibm.com
> lan...@us.ibm.com wrote:
>>Rex Dieter wrote:
>>
>>>We're trying to use Pcomm v5.6 (and v5.0) to connect to IBM's z/OS
>>>Communications Server (TCPIP) via SSL, and it only mysteriously fails
>>>with: error code 414
>>>no idea what that means, can't find it in the help, documentation, ibm's
>>>website, or googling.
>>>
>>>Connecting to this same server using qws3270 secure works.
>>>
>>>Hints/ideas?
>
>
>>The 414 is an SSL error code which in this case probably
>>means that the certificate presented by the z/OS tn server
>>was not in the key database that pcomm is using or the
>>signer of that server cert was not in pcomm's key database.
>
>
> The cert in question is signed by Verisign (or so I'm told by those admining
> the server in question), and Versign is in pcomm's list of CA's already (as
> shown by the Cert Manager anyway).
There are several 'Verisign CA' certs. When I use the Certificate
Management Utility on PCOMM 5.9 to create a NEW database it is seeded
with 12 Verisign CA certs and 11 more from other CAs. Your PCOMM 5.6
will have the CAs as they existed when PCOMM 5.6 was released and
some of those CA certs may be expired. Are you sure the one which
was used to sign the z/OS server's cert is in your list?
>>My guess is that qws3270 offered an 'accept this cert' pop-up,
>>just like many web browsers, and it sucked the public key info
>>into it's database automatically.
>
>
> qws3270 secure (supposedly) uses CA authorities too, but uses the
> implementation of cert management builtin to windows, not like PComm's
> separate-but-equal (re)implementation of the same thing. (:
The SSL support in PCOMM is code which is common to many IBM
products (HOD, HATS, IHS, CommServer) and many of those products
do not run on Windows (AIX, Linux, OS/2, z/OS), so a (re)implementation
was inevitable.
Paul Landay
Rex Dieter
> Rex Dieter wrote:
>> lan...@us.ibm.com wrote:
>>>Rex Dieter wrote:
>>>
>>>>We're trying to use Pcomm v5.6 (and v5.0) to connect to IBM's z/OS
>>>>Communications Server (TCPIP) via SSL, and it only mysteriously fails
>>>>with: error code 414
>>>>no idea what that means, can't find it in the help, documentation, ibm's
>>>>website, or googling.
>>>>
>>>>Connecting to this same server using qws3270 secure works.
>>>>
>>>>Hints/ideas?
>>
>>
>>>The 414 is an SSL error code which in this case probably
>>>means that the certificate presented by the z/OS tn server
>>>was not in the key database that pcomm is using or the
>>>signer of that server cert was not in pcomm's key database.
>> The cert in question is signed by Verisign (or so I'm told by those
>> admining the server in question), and Versign is in pcomm's list of CA's
>> already (as shown by the Cert Manager anyway).
> There are several 'Verisign CA' certs. When I use the Certificate
> Management Utility on PCOMM 5.9 to create a NEW database it is seeded
> with 12 Verisign CA certs and 11 more from other CAs. Your PCOMM 5.6
> will have the CAs as they existed when PCOMM 5.6 was released and
> some of those CA certs may be expired. Are you sure the one which
> was used to sign the z/OS server's cert is in your list?
I'll double-check, thanks.
Shouldn't the latest Pcomm 5.6.5 update include the newer CA's? (apparently
it doesn't).
-- Rex
-- Rex
lan...@us.ibm.com
>>>The cert in question is signed by Verisign (or so I'm told by those
>>>admining the server in question), and Versign is in pcomm's list of CA's
>>>already (as shown by the Cert Manager anyway).
>
>>There are several 'Verisign CA' certs. When I use the Certificate
>>Management Utility on PCOMM 5.9 to create a NEW database it is seeded
>>with 12 Verisign CA certs and 11 more from other CAs. Your PCOMM 5.6
>>will have the CAs as they existed when PCOMM 5.6 was released and
>>some of those CA certs may be expired. Are you sure the one which
>>was used to sign the z/OS server's cert is in your list?
>
> I'll double-check, thanks.
> Shouldn't the latest Pcomm 5.6.5 update include the newer CA's? (apparently
> it doesn't).
I am pretty sure the IBM products do not ship updates to the CA list.
This is for a couple of reasons:
- A 'merge' process would have to be developed to keep
from wiping out not-well-known-CAs, like a private CA,
and self-signed certs. You would probably want to
prompt users before doing this, adding to the complexity
of the update.
- Some very-security-aware customers (e.g. Banks) REMOVE
all the pre-defined CAs, to keep tighter control over
which certs are accepted and which are not. We would
not want to re-add CAs which had been explicitly
removed by the user. I know some products have gone
to shipping an empty CA list (not PCOMM).
When a new level of the base product is installed you may
get a new level of the common SSL code, which would have a
new set of pre-defined CAs.
Paul Landay
Rex Dieter
The server cert in question includes:
Issuer's Name:
>CN=VeriSign Class 3 Secure Server CA
Googling that turned up interesting reading on
http://www.verisign.com/support/advisories/page_029264.html
which implies this to be a relatively new CA, which led me to
http://www.verisign.com/support/advisories/page_040611.html
and
https://www.verisign.com/support/verisign-intermediate-ca/page_dev029204.html
which doesn't list anything explicitly labeled "VeriSign Class 3 Secure
Server CA", but I'll work my way through the list to try to find something
that works.
-- Rex
Rex Dieter
> Rex Dieter wrote:
>> Shouldn't the latest Pcomm 5.6.5 update include the newer CA's?
>> (apparently it doesn't).
>
> I am pretty sure the IBM products do not ship updates to the CA list.
> This is for a couple of reasons:
> - A 'merge' process would have to be developed to keep
> from wiping out not-well-known-CAs, like a private CA,
> and self-signed certs. You would probably want to
> prompt users before doing this, adding to the complexity
> of the update.
Merging would have been nice, and so would an app the "just works". (:
-- Rex
lan...@us.ibm.com
Try a variation of the "IBM HTTP Server" instructions at:
https://www.verisign.com/support/ssl-certificates-support/page_dev028341.html
If it is not already in PCOMM's key database you will need
both the 'Class 3 Public Primary Certification Authority'
and the 'Verisign Class 3 Secure Server CA' certs. These
two are pre-defined in PCOMM 5.9.
Paul Landay
Rex Dieter
> Try a variation of the "IBM HTTP Server" instructions at:
>
https://www.verisign.com/support/ssl-certificates-support/page_dev028341.html
> If it is not already in PCOMM's key database you will need
> both the 'Class 3 Public Primary Certification Authority'
> and the 'Verisign Class 3 Secure Server CA' certs. These
> two are pre-defined in PCOMM 5.9.
Thanks Paul, the latter item did the trick!
-- Rex