openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

ITS#8626 : TLS trace: SSL3 alert write:fatal:certificate unknown
by Anitha.Seshadri＠dell.com 30 Mar '17

30 Mar '17

--_000_15687A439BFEE848B596FFB9FB92A77B627F577AMX101CL01corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI We are using Openldap 2.4.33 (Linux 64 bit built with RSA MES 3.2.4.3 ) in= our application for LDAP synchronization. We have a customer case where the customer is using a certificate chain. Th= ey have converted the root and intermediate certificates into pem and are u= sing the pem to connect to the lDAP server. We are getting the below error : TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS trace: SSL_connect:SSLv3 process tls extension TLS trace: SSL_connect:SSL3 post/by-pass tls extension processing TLS trace: SSL_connect:SSLv3 read server certificate A TLS certificate verification: depth: 0, err: 0, subject: /CN=3DITSUSRANADC5= 5.na.jnj.com, issuer: /DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA C2 TLS certificate verification: depth: 1, err: 0, subject: /DC=3Dcom/DC=3Djnj= /CN=3DJNJ Internal Online CA C2, issuer: /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Intern= al Root Certification Authority TLS certificate verification: depth: 2, err: 0, subject: /DC=3DCOM/DC=3DJNJ= /CN=3DJNJ Internal Root Certification Authority, issuer: /DC=3DCOM/DC=3DJNJ= /CN=3DJNJ Internal Root Certification Authority TLS trace: SSL3 alert write:fatal:certificate unknown TLS trace: SSL_connect:error in SSL3 certificate verify A TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE= :certificate verify failed (ok). After Calling ldap_int_open_connection rc =3D 0 LDAP_SERVER_DOWN The same certificate (pem) connects perfectly with openssl commands. [dmfs4adm@itsusral00157 ldapdb]$ openssl s_client -CAfile /dmfs4/apps/docum= entum/dba/secure/ldapdb/INT-PROD-Root-Intermedia_0320.pem -connect ITSUSRAN= ADC41.na.j nj.com:3269 CONNECTED(00000003) depth=3D2 DC =3D COM, DC =3D JNJ, CN =3D JNJ Internal Root Certification Au= thority verify return:1 depth=3D1 DC =3D com, DC =3D jnj, CN =3D JNJ Internal Online CA A2 verify return:1 depth=3D0 CN =3D ITSUSRANADC41.na.jnj.com verify return:1 - Certificate chain 0 s:/CN=3DITSUSRANADC41.na.jnj.com i:/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A2 1 s:/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A2 i:/DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certification Authority - Server certificate ----BEGIN CERTIFICATE---- MIIG0zCCBbugAwIBAgIKNPjZjAAAANPqDjANBgkqhkiG9w0BAQUFADBOMRMwEQYK CZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDam5qMSIwIAYDVQQDExlK TkogSW50ZXJuYWwgT25saW5lIENBIEEyMB4XDTE2MDkwNjIzMTI0M1oXDTE3MDkw NjIzMTI0M1owIzEhMB8GA1UEAxMYSVRTVVNSQU5BREM0MS5uYS5qbmouY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlmJd7MNGtotF5zXbWJdSaezG LDk1ty98yceBIDz6P1JIYAP84QtEMA+xO3GW7Y+oPjBtMjoEd7P1gLmCVxC9zf69 GNOgYjMsjo4QbynPcgcxMGnpwj8yHQVPLkRe7Do2qpfDz3jhVRT7cJ+u3xu+z66x /JbhCrySeekqL9O6O96YpqMFi+897Lgg9QPphjgrvrD5VmxHfH0V7p7sc/DcIufJ Ifjj7DGotaffcc90VZxj+vQd1iO5AchaDkIUiPLES9AsbcXei8Fau6pcFKpQBh5l fynm73EU01FP+RN//6WpyoIVXVc5uTE9ua7q+O2nGb46FnKlegGpI3iJCh5NJwID AQABo4ID3DCCA9gwOwYJKwYBBAGCNxUHBC4wLAYkKwYBBAGCNxUIgtGfI5rtGIad nTSHnpIqh8HUUmmEo+JQuZUUAgFkAgEFMDMGA1UdJQQsMCoGCCsGAQUFCAICBgor BgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQDAgWgMBgG A1UdIAQRMA8wDQYLYIZIAYb4AgMCAQowQQYJKwYBBAGCNxUKBDQwMjAKBggrBgEF BQgCAjAMBgorBgEEAYI3FAICMAoGCCsGAQUFBwMBMAoGCCsGAQUFBwMCMIGjBgNV HREEgZswgZiCGElUU1VTUkFOQURDNDEubmEuam5qLmNvbYIKbmEuam5qLmNvbYIN bmFkaXIuam5qLmNvbYITbmFsZWdhY3lkaXIuam5qLmNvbYITbmFuZXh0b3NkaXIu am5qLmNvbYIQbmFpY2VkaXIuam5qLmNvbYIUbmFzcGVjaWFsZGlyLmpuai5jb22C D25hZndkaXIuam5qLmNvbTAdBgNVHQ4EFgQU11fVbuyGZpo8ApfMelvW1TFrH3ow HwYDVR0jBBgwFoAUhlNccpOupTSpisgGUUr+XzVQOeEwggEJBgNVHR8EggEAMIH9 MIH6oIH3oIH0hoHKbGRhcDovLy9DTj1KTkolMjBJbnRlcm5hbCUyME9ubGluZSUy MENBJTIwQTIsQ049SVRTVVNSQUpOSkNBMyxDTj1DRFAsQ049UHVibGljJTIwS2V5 JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1qbmos REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFz cz1jUkxEaXN0cmlidXRpb25Qb2ludIYlaHR0cDovL2ludHByb2Rjcmwuam5qLmNv bS9pbnRjYWEyLmNybDCCAQIGCCsGAQUFBwEBBIH1MIHyMIG8BggrBgEFBQcwAoaB r2xkYXA6Ly8vQ049Sk5KJTIwSW50ZXJuYWwlMjBPbmxpbmUlMjBDQSUyMEEyLENO PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPWpuaixEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29i amVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwMQYIKwYBBQUHMAKGJWh0 dHA6Ly9pbnRwcm9kcGtpLmpuai5jb20vaW50Y2FhMi5wN2MwDQYJKoZIhvcNAQEF BQADggEBAE1hMzal6XiA0Rz1zsTlqAvZiXJg9urK/FcoeL4kiSGCVXQFPYZPRRG7 cwVBTkqABfNvTr2L7WTr2wqZL25HjY4hphK97I4BvCydpQLCEYPiSatY8kFN8Mpu rDTqNlzTEKt7qId9yDrsKmOI+Gs3hHrWPri1fdOeSlkwIUN5gKCwdH/h44LYU8Z5 4tSjWAkh0hkOU0pija45i7tkBzTholXoOEmAmv7G9UlhLuk950yLzu58yW4aBda1 rev0YtUsKjpfSbTWRwcxeYhspcEq2oGYsWD47wLxQJXHUiRWcXyYuOKiQiu4gjZ7 hS9/xvPvJ3zvxHoI7qF4A8VBgF8c4lQ=3D ----END CERTIFICATE---- subject=3D/CN=3DITSUSRANADC41.na.jnj.com issuer=3D/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A2 - Acceptable client certificate CA names /CN=3DITSUSRANADC41.na.jnj.com /C=3DSE/O=3DAddTrust AB/OU=3DAddTrust External TTP Network/CN=3DAddTrust Ex= ternal CA Roo t /C=3DUS/O=3DJNJ/OU=3DJNJ Public Key Authorities/CN=3DJNJ 2048bit Root Certi= fication Auth ority /C=3DUS/O=3DJNJ/OU=3DJNJ Public Key Authorities/CN=3DJNJ Root Certification= Authority /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certification Authority /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Network/OU=3D(c) 2008 VeriSi= gn, Inc. - Fo r authorized use only/CN=3DVeriSign Universal Root Certificat= ion Authority /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Network/OU=3D(c) 2006 VeriSi= gn, Inc. - Fo r authorized use only/CN=3DVeriSign Class 3 Public Primary Ce= rtification Authority - G5 /C=3DUS/O=3DVeriSign, Inc./OU=3DClass 3 Public Primary Certification Author= ity /C=3DUS/O=3DVeriSign, Inc./OU=3DClass 3 Public Primary Certification Author= ity - G2/OU =3D(c) 1998 VeriSign, Inc. - For authorized use only/OU=3DVeriS= ign Trust Network /C=3DUS/ST=3DWashington/L=3DRedmond/O=3DMicrosoft Corporation/CN=3DMicrosof= t Root Certific ate Authority 2011 /C=3DUS/O=3DGTE Corporation/OU=3DGTE CyberTrust Solutions, Inc./CN=3DGTE Cy= berTrust Glob al Root /C=3DIE/O=3DBaltimore/OU=3DCyberTrust/CN=3DBaltimore CyberTrust Root /C=3DUS/ST=3DWashington/L=3DRedmond/O=3DMicrosoft Corporation/CN=3DMicrosof= t Root Certific ate Authority 2010 /O=3DSymantec Corporation/CN=3DSymantec Root CA /OU=3DCopyright (c) 1997 Microsoft Corp./OU=3DMicrosoft Corporation/CN=3DMi= crosoft Roo t Authority /C=3DUS/O=3DSymantec Corporation/CN=3DSymantec Root 2005 CA /DC=3Dcom/DC=3Dmicrosoft/CN=3DMicrosoft Root Certificate Authority /CN=3DNT AUTHORITY - SSL handshake has read 5700 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: 743C00003D9B50EAA53C45E670C3E9682DBE86BA873CEA5B35BFB16B7CE5A62= 5 Session-ID-ctx: Master-Key: 0DB1DB6C4E9B3BE57E6E3A38B3A68EACAF96A78650EA978B4A8860B35BBDCCB= 4 61DA777F8C0D83ED53CCFE82748D3F86 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1490103903 Timeout : 300 (sec) Verify return code: 0 (ok) - Could you let us know what we could be missing here? The pem contains certificates JNJ Internal Root Certification Authority and= CN=3DJNJ Internal Online CA C2 .Are we missing anything here? Any help would be greatly appreciated. Thanks Anitha --_000_15687A439BFEE848B596FFB9FB92A77B627F577AMX101CL01corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> HI<o:p></o:p> <o:p> </o:p> We are using Openldap 2.4.33 (Linux 64 bit  bui= lt with RSA MES 3.2.4.3 ) in our application for LDAP synchronization.<o:p>= </o:p> We have a customer case where the customer is using = a certificate chain. They have converted the root and intermediate certific= ates into pem and are using the pem to connect to the lDAP server.<o:p></o:= p> We are getting the below error :<o:p></o:p> <o:p> </o:p> TLS trace: SSL_connect:before/connect initialization= <o:p></o:p> TLS trace: SSL_connect:SSLv3 write client hello A<o:= p></o:p> TLS trace: SSL_connect:SSLv3 read server hello A<o:p= ></o:p> TLS trace: SSL_connect:SSLv3 process tls extension<o= :p></o:p> TLS trace: SSL_connect:SSL3 post/by-pass tls extensi= on processing<o:p></o:p> TLS trace: SSL_connect:SSLv3 read server certificate= A<o:p></o:p> TLS certificate verification: depth: 0, err: 0, subj= ect: /CN=3DITSUSRANADC55.na.jnj.com, issuer: /DC=3Dcom/DC=3Djnj/CN=3DJNJ In= ternal Online CA C2<o:p></o:p> TLS certificate verification: depth: 1, err: 0, subj= ect: /DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA C2, issuer: /DC=3DCOM/D= C=3DJNJ/CN=3DJNJ Internal Root Certification Authority<o:p></o:p> TLS certificate verification: depth: 2, err: 0, subj= ect: /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certification Authority, iss= uer: /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certification Authority<o:p>= </o:p> TLS trace: SSL3 alert write:fatal:certificate unknown<o:p></o:p><= /p> TLS trace: SSL_connect:error in SSL3 certificate verify A<o:p></o:p></sp= an> TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFIC= ATE:certificate verify failed (ok).<o:p></o:p> After Calling ldap_int_open_connection rc =3D 0<o:p>= </o:p> LDAP_SERVER_DOWN<o:p></o:p> <o:p> </o:p> The same certificate (pem) connects perfectly with o= penssl commands.<o:p></o:p> <o:p> </o:p> [dmfs4adm@itsusral00157 ldapdb]$ openssl s_client -CAfile /dmfs4/apps/do= cumentum/dba/secure/ldapdb/INT-PROD-Root-Intermedia_0320.pem -connect ITSUS= RANADC41.na.j nj.com:3269<o:p></o:p> CONNECTED(00000003)<o:p></o:p> depth=3D2 DC =3D COM, DC =3D JNJ, CN =3D JNJ Interna= l Root Certification Authority<o:p></o:p> verify return:1<o:p></o:p> depth=3D1 DC =3D com, DC =3D jnj, CN =3D JNJ Interna= l Online CA A2<o:p></o:p> verify return:1<o:p></o:p> depth=3D0 CN =3D ITSUSRANADC41.na.jnj.com<o:p></o:p>= verify return:1<o:p></o:p> —<o:p></o:p> Certificate chain<o:p></o:p> 0 s:/CN=3DITSUSRANADC41.na.jnj.com<o:p></o:p> i:/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A2<= o:p></o:p> 1 s:/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A= 2<o:p></o:p> i:/DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certific= ation Authority<o:p></o:p> —<o:p></o:p> Server certificate<o:p></o:p> ----BEGIN CERTIFICATE----<o:p></o:p> MIIG0zCCBbugAwIBAgIKNPjZjAAAANPqDjANBgkqhkiG9w0BAQUF= ADBOMRMwEQYK<o:p></o:p> CZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDam5qMSIw= IAYDVQQDExlK<o:p></o:p> TkogSW50ZXJuYWwgT25saW5lIENBIEEyMB4XDTE2MDkwNjIzMTI0= M1oXDTE3MDkw<o:p></o:p> NjIzMTI0M1owIzEhMB8GA1UEAxMYSVRTVVNSQU5BREM0MS5uYS5q= bmouY29tMIIB<o:p></o:p> IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlmJd7MNGtotF= 5zXbWJdSaezG<o:p></o:p> LDk1ty98yceBIDz6P1JIYAP84QtEMA+xO3GW7Y+oPjBt= MjoEd7P1gLmCVxC9zf69<o:p></o:p> GNOgYjMsjo4QbynPcgcxMGnpwj8yHQVPLkRe7Do2qpfDz3jhVRT7= cJ+u3xu+z66x<o:p></o:p> /JbhCrySeekqL9O6O96YpqMFi+897Lgg9QPphjgrvrD5VmxH= fH0V7p7sc/DcIufJ<o:p></o:p> Ifjj7DGotaffcc90VZxj+vQd1iO5AchaDkIUiPLES9AsbcXe= i8Fau6pcFKpQBh5l<o:p></o:p> fynm73EU01FP+RN//6WpyoIVXVc5uTE9ua7q+O2nGb46= FnKlegGpI3iJCh5NJwID<o:p></o:p> AQABo4ID3DCCA9gwOwYJKwYBBAGCNxUHBC4wLAYkKwYBBAGCNxUI= gtGfI5rtGIad<o:p></o:p> nTSHnpIqh8HUUmmEo+JQuZUUAgFkAgEFMDMGA1UdJQQsMCoG= CCsGAQUFCAICBgor<o:p></o:p> BgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/= BAQDAgWgMBgG<o:p></o:p> A1UdIAQRMA8wDQYLYIZIAYb4AgMCAQowQQYJKwYBBAGCNxUKBDQw= MjAKBggrBgEF<o:p></o:p> BQgCAjAMBgorBgEEAYI3FAICMAoGCCsGAQUFBwMBMAoGCCsGAQUF= BwMCMIGjBgNV<o:p></o:p> HREEgZswgZiCGElUU1VTUkFOQURDNDEubmEuam5qLmNvbYIKbmEu= am5qLmNvbYIN<o:p></o:p> bmFkaXIuam5qLmNvbYITbmFsZWdhY3lkaXIuam5qLmNvbYITbmFu= ZXh0b3NkaXIu<o:p></o:p> am5qLmNvbYIQbmFpY2VkaXIuam5qLmNvbYIUbmFzcGVjaWFsZGly= Lmpuai5jb22C<o:p></o:p> D25hZndkaXIuam5qLmNvbTAdBgNVHQ4EFgQU11fVbuyGZpo8ApfM= elvW1TFrH3ow<o:p></o:p> HwYDVR0jBBgwFoAUhlNccpOupTSpisgGUUr+XzVQOeEwggEJ= BgNVHR8EggEAMIH9<o:p></o:p> MIH6oIH3oIH0hoHKbGRhcDovLy9DTj1KTkolMjBJbnRlcm5hbCUy= ME9ubGluZSUy<o:p></o:p> MENBJTIwQTIsQ049SVRTVVNSQUpOSkNBMyxDTj1DRFAsQ049UHVi= bGljJTIwS2V5<o:p></o:p> JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv= bixEQz1qbmos<o:p></o:p> REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v= YmplY3RDbGFz<o:p></o:p> cz1jUkxEaXN0cmlidXRpb25Qb2ludIYlaHR0cDovL2ludHByb2Rj= cmwuam5qLmNv<o:p></o:p> bS9pbnRjYWEyLmNybDCCAQIGCCsGAQUFBwEBBIH1MIHyMIG8Bggr= BgEFBQcwAoaB<o:p></o:p> r2xkYXA6Ly8vQ049Sk5KJTIwSW50ZXJuYWwlMjBPbmxpbmUlMjBD= QSUyMEEyLENO<o:p></o:p> PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2= aWNlcyxDTj1D<o:p></o:p> b25maWd1cmF0aW9uLERDPWpuaixEQz1jb20/Y0FDZXJ0aWZpY2F0= ZT9iYXNlP29i<o:p></o:p> amVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwMQYIKwYB= BQUHMAKGJWh0<o:p></o:p> dHA6Ly9pbnRwcm9kcGtpLmpuai5jb20vaW50Y2FhMi5wN2MwDQYJ= KoZIhvcNAQEF<o:p></o:p> BQADggEBAE1hMzal6XiA0Rz1zsTlqAvZiXJg9urK/FcoeL4kiSGC= VXQFPYZPRRG7<o:p></o:p> cwVBTkqABfNvTr2L7WTr2wqZL25HjY4hphK97I4BvCydpQLCEYPi= SatY8kFN8Mpu<o:p></o:p> rDTqNlzTEKt7qId9yDrsKmOI+Gs3hHrWPri1fdOeSlkwIUN5= gKCwdH/h44LYU8Z5<o:p></o:p> 4tSjWAkh0hkOU0pija45i7tkBzTholXoOEmAmv7G9UlhLuk950yL= zu58yW4aBda1<o:p></o:p> rev0YtUsKjpfSbTWRwcxeYhspcEq2oGYsWD47wLxQJXHUiRWcXyY= uOKiQiu4gjZ7<o:p></o:p> hS9/xvPvJ3zvxHoI7qF4A8VBgF8c4lQ=3D<o:p></o:p> ----END CERTIFICATE----<o:p></o:p> subject=3D/CN=3DITSUSRANADC41.na.jnj.com<o:p></o:p><= /p> issuer=3D/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online= CA A2<o:p></o:p> —<o:p></o:p> Acceptable client certificate CA names<o:p></o:p></p= > /CN=3DITSUSRANADC41.na.jnj.com<o:p></o:p> /C=3DSE/O=3DAddTrust AB/OU=3DAddTrust External TTP N= etwork/CN=3DAddTrust External CA Roo t<o:p></o:p> /C=3DUS/O=3DJNJ/OU=3DJNJ Public Key Authorities/CN= =3DJNJ 2048bit Root Certification Auth ority<o:p></o:p> /C=3DUS/O=3DJNJ/OU=3DJNJ Public Key Authorities/CN= =3DJNJ Root Certification Authority<o:p></o:p> /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certificat= ion Authority<o:p></o:p> /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Netwo= rk/OU=3D(c) 2008 VeriSign, Inc. - Fo r authorized use only/CN=3DVeriSign Un= iversal Root Certification Authority<o:p></o:p> /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Netwo= rk/OU=3D(c) 2006 VeriSign, Inc. - Fo r authorized use only/CN=3DVeriSign Cl= ass 3 Public Primary Certification Authority - G5<o:p></o:p> /C=3DUS/O=3DVeriSign, Inc./OU=3DClass 3 Public Prima= ry Certification Authority<o:p></o:p> /C=3DUS/O=3DVeriSign, Inc./OU=3DClass 3 Public Prima= ry Certification Authority - G2/OU =3D(c) 1998 VeriSign, Inc. - For authori= zed use only/OU=3DVeriSign Trust Network<o:p></o:p> /C=3DUS/ST=3DWashington/L=3DRedmond/O=3DMicrosoft Co= rporation/CN=3DMicrosoft Root Certific ate Authority 2011<o:p></o:p> /C=3DUS/O=3DGTE Corporation/OU=3DGTE CyberTrust Solu= tions, Inc./CN=3DGTE CyberTrust Glob al Root<o:p></o:p> /C=3DIE/O=3DBaltimore/OU=3DCyberTrust/CN=3DBaltimore= CyberTrust Root<o:p></o:p> /C=3DUS/ST=3DWashington/L=3DRedmond/O=3DMicrosoft Co= rporation/CN=3DMicrosoft Root Certific ate Authority 2010<o:p></o:p> /O=3DSymantec Corporation/CN=3DSymantec Root CA<o:p>= </o:p> /OU=3DCopyright (c) 1997 Microsoft Corp./OU=3DMicros= oft Corporation/CN=3DMicrosoft Roo t Authority<o:p></o:p> /C=3DUS/O=3DSymantec Corporation/CN=3DSymantec Root = 2005 CA<o:p></o:p> /DC=3Dcom/DC=3Dmicrosoft/CN=3DMicrosoft Root Certifi= cate Authority<o:p></o:p> /CN=3DNT AUTHORITY<o:p></o:p> —<o:p></o:p> SSL handshake has read 5700 bytes and written 619 by= tes<o:p></o:p> —<o:p></o:p> New, TLSv1/SSLv3, Cipher is AES128-SHA256<o:p></o:p>= Server public key is 2048 bit<o:p></o:p> Secure Renegotiation IS supported<o:p></o:p> Compression: NONE<o:p></o:p> Expansion: NONE<o:p></o:p> SSL-Session:<o:p></o:p> Protocol : TLSv1.2<o:p></o:p> Cipher : AES128-SHA256<o:p></o:p> Session-ID: 743C00003D9B50EAA53C45E670C3E9682DBE86BA= 873CEA5B35BFB16B7CE5A625<o:p></o:p> Session-ID-ctx:<o:p></o:p> Master-Key: 0DB1DB6C4E9B3BE57E6E3A38B3A68EACAF96A786= 50EA978B4A8860B35BBDCCB4 61DA777F8C0D83ED53CCFE82748D3F86<o:p></o:p> Key-Arg : None<o:p></o:p> Krb5 Principal: None<o:p></o:p> PSK identity: None<o:p></o:p> PSK identity hint: None<o:p></o:p> Start Time: 1490103903<o:p></o:p> Timeout : 300 (sec)<o:p></o:p> Verify return code: 0 (ok)<o:p></o:p> —<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Could you let us know what we could be missing here?= <o:p></o:p> <o:p> </o:p> The pem contains certificates JNJ Internal Root Cert= ification Authority and CN=3DJNJ Internal Online CA C2 .Are we missing &nbs= p;anything here?<o:p></o:p> Any help would be greatly appreciated.<o:p></o:p></p= > <o:p> </o:p> Thanks<o:p></o:p> Anitha<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html> --_000_15687A439BFEE848B596FFB9FB92A77B627F577AMX101CL01corpem_--

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by ondra＠mistotebe.net 30 Mar '17

30 Mar '17

The patches are available at ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170330-slapmodify-BerkeleyD… -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#7387) ldapcppei contribution
by quanah＠symas.com 29 Mar '17

29 Mar '17

Hello Philippe, Thanks for looking to contribute to the OpenLDAP project. Your submission does not appear to have followed the submission guidelines for the project, located at: <http://www.openldap.org/devel/contributing.html> In addition, I would note the following: a) How does this submission differ from, or improve upon, the ldapc++ API that is already shipped with OpenLDAP? b) Your chosen license may cause your contribution to be rejected (See contribution guidelines). If you would still like your work to be included with the OpenLDAP project, please review the contribution guidelines and follow up to the ITS with the proper format, etc. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7085) mutex lockup issue
by quanah＠symas.com 29 Mar '17

29 Mar '17

Hi Soichi, I was curious if you still encounter this issue using current OpenLDAP and back-mdb. I would note the back-bdb/hdb backends are now deprecated. It also occurred to me that the issue may have been related to lack of lock resources, etc (which are generally set in DB_CONFIG). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7700) DOC: OL AdminGuide not updated
by quanah＠symas.com 29 Mar '17

29 Mar '17

Just wanted to follow up and let you know that these issues have been addressed for the 2.4.45 release. Thanks for the report! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8391) peername string starts with "IP=" not "IP:"
by subbarao＠computer.org 29 Mar '17

29 Mar '17

Thanks! On 03/29/2017 02:53 PM, Quanah Gibson-Mount wrote: > --On Friday, March 25, 2016 3:22 PM +0000 subbarao(a)computer.org wrote: > >> Full_Name: Kartik Subbarao >> Version: 2.4.41 >> OS: Ubuntu 14.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (108.16.127.8) >> >> >> There is an error in the ACL section of the OpenLDAP Software 2.4 >> Administrator's guide: >> >> http://www.openldap.org/devel/admin/slapdconf2.html >> >> In the following line: >> >> by peername.regex=IP:10\..+ read >> >> Instead of "IP:", the correct syntax is "IP=". >> >> by peername.regex=IP=10\..+ read >> > > Thanks, fixed. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by quanah＠symas.com 29 Mar '17

29 Mar '17

Hi Jan, I've applied the SASL_NOCANON patch that was missed previously. Thanks for the submission! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8499) fixes documentation typo
by quanah＠symas.com 29 Mar '17

29 Mar '17

--On Sunday, September 11, 2016 4:48 PM +0000 gerardo.santana(a)gmail.com wrote: > Full_Name: Gerardo Santana Gomez Garrido > Version: 2.4 > OS: Mac OS X > URL: ftp://ftp.openldap.org/incoming/gerardo-santana-160911.patch > Submission from: (NULL) (70.113.112.97) > > > documentation typo > Thanks for the report. This has been applied. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8391) peername string starts with "IP=" not "IP:"
by quanah＠symas.com 29 Mar '17

29 Mar '17

--On Friday, March 25, 2016 3:22 PM +0000 subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.41 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.16.127.8) > > > There is an error in the ACL section of the OpenLDAP Software 2.4 > Administrator's guide: > > http://www.openldap.org/devel/admin/slapdconf2.html > > In the following line: > > by peername.regex=IP:10\..+ read > > Instead of "IP:", the correct syntax is "IP=". > > by peername.regex=IP=10\..+ read > Thanks, fixed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8587) correct spelling errors: wrong: emtpy, correct: empty
by quanah＠symas.com 29 Mar '17

29 Mar '17

--On Saturday, February 11, 2017 9:46 PM +0000 sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: RE24 testing call (2.4.45) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-20170211-2.patch > Submission from: (NULL) (2001:a60:f0b4:e502:80b6:610b:8fc2:abfe) > > > there are 4 occurrence of "emtpy" which are supposed to be written as > "empty" Thanks for the report. In the future, please use git-format-patch, as noted in the contributing guidelines: <http://www.openldap.org/devel/contributing.html#patches> Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs