Connecting to an SSL web service

OpenEdge looks for the issuing CA's digital certificate(s) in $DLC/certs when performing the server validation step in creating an SSL connection.  The certificates stored in $DLC/certs use a file name that is a hash of the certificate's subject name field followed by a '.0' file extension.   A form of indexing to find a certificate file based on a certificate's subject name field and not on what someone decides to name it.   Odd, but true.

In this case it was looking for the digital certificate of the CA who issued the SSL server's certificate under the file name 7999be0d.0.   You'll need to get a copy of the CA's digital certificate (".crt" ?? ) and import it into the $DLC/certs directory.   When you have imported the correct CA certificate you will have a file named $DLC/certs/7999be0d.0

The $DLC/bin/certutil utility allows you to import, list, and display the certificates stored in $DLC/certs.

Yes I have the named certificate file and imported into my Progress/OpenEdge/certs folder. Then I run my .p with the CONNECT statement but still get the error and there is no 7999be0d.0 file in the certs folder after refreshing.

I get this invalid option message. I need to use the -format since the default is PEM and mine is DER.

proenv>certutil -import 'C:\Progress\OpenEdge\certs\.cer' -format DER

Invalid option -format found after operation arguments

proenv

Actually I get the following. The .der file is in my $DLC/certs folder.

proenv>certutil -import certname.der

The certificate file to import certname.der does not exist

I tried this too but to no avail:

proenv>mkhashfile certname.crt.pem

OpenEdge Release 10.1C04 as of Sat May 30 00:40:18 EDT 2009

Running SSLC command ...

Error running sslc command, unable to create hash file

The .cer certificate files I see have generally been of PEM type.   So the defaults from 'certutil' should work.  I will verify a certificate file's type using certutil -display before trying to import it.   Last check, a PEM file begins with a line "-----BEGIN CERTIFICATE-----" and end with the line "-----END CERTIFICATE-----".

The certutil's options like format, brief, and verbose are positional and must come before the -import operation.

After importing, I generally validate the import using 'certutil -brief -list' and ensure the is listed.

I would recommend against using 'mkhashfile'.

If you still do not get the correct .0 file in the $DLC/certs directory, something is amiss and would have to do deeper inspection on the certificate file and its contents against the SSL server's certificate.

Yes thanks. The problem was that I had to navigate to the certs folder to get certutil to work since current directory was in c:\openedge\WRK. Anyways it did create a hashed file of .0 now. Thanks again

Unfortunately when I import the cert file I do not get the hashed alias file of 7999be0d.0 that I was expecting and that the server is excepting when I run CONNECT. Is it my CONNECT statement?

It is not your CONNECT.   The SSL certificate validation looksk for certificates in $DLC/certs by creating a hashed file name from the server certificate's 'subject' name field.   The server certificate is obtained from the SSL server's configuration and is transmitted to the client during the SSL connection handshake.   In short, you have no conrol over it.

We are at the point of directly inspecting the certificate you are trying to import.   Are you able to e-mail that to me?

Thanks Michael. I haven't had time to work with my network admin person yet... I suspect the method (from IE) where I got the cert was not right...

require import the certificate of the entity that awarded the certificate to the Web service you want to connect ..

The Web service to which you want to connect has a certificate, the certificate is awarded at the entity X.

Require the certificate of the entity X