0

I am helping out with an issue connecting with an ADFS server.
As my area of expertise includes linux I ran the following command - well almost I changed the IP address - 

OpenSSL> s_client -connect 106.678.123.456:636 -showcerts   
..  
CONNECTED(00000003)   
depth=0  
verify error:num=20:unable to get local issuer certificate  
verify return:1  
depth=0  
verify error:num=27:certificate not trusted  
verify return:1  
depth=0  
verify error:num=21:unable to verify the first certificate  
verify return:1

Evidently the ADFS should take steps so the above command runs without an error. But what? Could someone help with that?

Edit: I found a post here
"verify error:num=20" when connecting to gateway.sandbox.push.apple.com
which indicates I took took much away from the openssl output

Let me fix that below
Only 4 changes made - the IP has been changed and the 3 letters identifying the company has been changed to XYZ - i:/DC=local/DC=RDM/CN=XYZ-SVR019-CA plus
I removed some of the actual cert and the Master-Key for privacy reasons

The subject really is empty 

openSSL> s_client -connect 106.678.123.456:636 -showcerts   
CONNECTED(00000003)   
depth=0   
verify error:num=20:unable to get local issuer certificate 
verify return:1   
depth=0   
verify error:num=27:certificate not trusted   
verify return:1   
depth=0   
verify error:num=21:unable to verify the first certificate  
verify return:1   
--- 
Certificate chain   
0 s:   
i:/DC=local/DC=RDM/CN=XYZ-SVR019-CA  
-----BEGIN CERTIFICATE-----   
MIIFljCCBH6gAwIBAgITcAAAADmcA9tVRxdmtwAAAAAAOTANBgkqhkiG9w0BAQUF  
...   
YwWjkDS6RqBf+9C4rEIhhUpYBqMlLh0Cy7xYUMR2moEPYSBQ6HxCLSgv  
-----END CERTIFICATE-----   
Server certificate 
subject=  
issuer=/DC=local/DC=RDM/CN=XYZ-SVR019-CA  
--- 
No client certificate CA names sent 
--- 
SSL handshake has read 1655 bytes and written 619 bytes 
--- 
New, TLSv1/SSLv3, Cipher is AES128-SHA256  

Server public key is 2048 bit 
Secure Renegotiation IS supported  

Compression: NONE  
Expansion: NONE 

SSL-Session:  
Protocol : TLSv1.2  
Cipher : AES128-SHA256  
Session-ID: 6B25000069CFD515953FDDDE1C3A3560DBE74FC271CA525BDA7BD2348C7F47F5  
Session-ID-ctx:  
Master-Key: C4......9A  
Key-Arg : None   
Krb5 Principal: None  
PSK identity: None   
PSK identity hint: None  
Start Time: 1467282145  
Timeout : 300 (sec)   
Verify return code: 21 (unable to verify the first certificate)
Community
  • 1
  • 1
tony bar
  • 21
  • 3
  • oops bad formatting - fixed now – tony bar Jul 01 '16 at 19:31
  • Referring to a post here – tony bar Jul 02 '16 at 04:34
  • and what is your question? – Crypt32 Jul 02 '16 at 07:42
  • OpenSSL> s_client -connect 106.678.123.456:636 -showcerts come back with an error "certificate not trusted" What actions should the ADFS admin take to fix the issue? A secondary question is can the subject be empty? – tony bar Jul 02 '16 at 08:30
  • it seems that ADFS cert is issued by an authority which is not trusted by a client. You should install root certificate to trusted store. – Crypt32 Jul 02 '16 at 09:21
  • Subject can be empty. In this case server names must be presented in a Subject Alternative Names certificate extension and this extension must be marked as critical. – Crypt32 Jul 02 '16 at 09:22
  • Hi CryptoGuy, Thanks for your responses. I did some googling as a result. It seems that if the ADFS server is an IDP and will be used for SAML SSO then there must be a FQDN in public DNS and this FQDM should be in the Subject. Plus IDP should not used self-signed certs. Have I got that right? – tony bar Jul 04 '16 at 06:53
  • As I said, Subject field is not necessary if subject names are listed in the SAN extension. – Crypt32 Jul 04 '16 at 10:53

0 Answers0