Kbase P160945: How is Progress deciding which certs are trusted?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/3/2010 |
|
Status: Unverified
GOAL:
Which public certs to use?
GOAL:
Are private certificates useful?
GOAL:
How is Progress deciding which certs are trusted?
FACT(s) (Environment):
OpenEdge 10.x
All Supported Operating Systems
FIX:
An SSL server's certificate must be issued by a CA who has signed the
server's certificate using its CA root certificate. So there are are a
minimum of two certificates involved. While private, self-signed,
certificates exist, they effectively have zero trust value.
The two certificates required are:
a) The server's digital certificate
(The digital certificate's Subject & Issuer field may NOT contain the same value)
b) The CA's root digital certificate that is used to digitally
sign the server's digital certificate
(The digital certificate's Subject & Issuer field must contain the same value)
Example:
Server's certificate signed by CA1
( Subject: cn=test.server.com ; Issuer: cn=CA1.com )
CA1's certificate signed by CA1
( Subject: cn=CA1.com ; Issuer: cn=CA1.com )
Note: It is legal to have certificate 'chains' where there are multiple CAs
Server's certificate signed by CA1
( Subject: cn=test.server.com ; Issuer: cn=CA1.com )
CA1's certificate signed by CA2
( Subject: cn=CA1.com ; Issuer: cn=CA2.com )
CA2's certificate signed by CA3
( Subject: cn=CA2.com ; Issuer: cn=CA3.com )
CA3's certificate signed by CA3
( Subject: cn=CA3.com ; Issuer: cn=CA3.com )
OpenEdge ABL clients do standard digital certificate validation by
looking up a certificate's Issuer CA/root certificate in $DLC/certs. It
does a specific check of the SSL server's certificate to exclude
self-signed certificates. OpenEdge ships a (very) few, but customers
may add any CA's root certificate to $DLC/certs at any time.
The following command can be used to review the certificate chain:
$DLC/bin/sslc s_client -connect hostname:port -showcerts -CApath $DLC/certs