florianz1 Absent Member.
Absent Member.
562 views

ldap: transient SSL_CTX_use_KMO failed. Error stack:

battle to get ldap use a new certificate (edir 9.0.3)

wanted to throw in what cost me some time to get it done, maybe somebody can guess
what's might be the issue here, because this made no sense to me.

several applications authenticate against our edirectory infrastructure through
ldap. the certificate ldap is using has SANs defined, to be able to talk to the
'address' the server by using an dns-alias. the alias has an '_' (underscore) in
its name. a new java application did not like that (even it should be legal by
dns-specification for some years now), so i wanted to quickly fix that
by adding an additional dns-alias without an underscore. then create a new certificate
having those in the SAN attribute as well.

unfortunately the ldap-interface refused to work with that one (i did make the private key
exportable, as i had issues with that in the past: https://forums.novell.com/showthread.php/504444-Disabling-TLS-services-because-of-configuration-failure?p=2461545#post2461545)

tracing pki / ldap said:
----------------------
09:34:17 1BC0 LDAP: LDAP Agent for NetIQ eDirectory 9.0.3 (40005.15) started
09:34:17 1BC0 LDAP: Updating server configuration
09:34:17 1BC0 LDAP: Work info status: Total:2 Peak:2 Busy:0
09:34:17 884 LDAP: Listener applying new configuration
09:34:17 884 LDAP: LDAPURL: ldap://:389
09:34:17 884 LDAP: LDAPURL: ldaps://:636
09:34:17 884 LDAP: Listener setting up cleartext port 389
09:34:17 884 LDAP: Listener setting up TLS port 636
09:34:17 884 LDAP: SSLv3 disabled for secure LDAP connections.
09:34:17 884 LDAP: TLS MEDIUM ciphers or higher required for TLS connections
09:34:17 884 LDAP: TLS initialization successfully completed
09:34:17 884 PKIAPI: NPKIGetServerKMOInfo called
09:34:17 884 PKIAPI: NPKIGetServerKMOInfo exiting with -1219
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - begin
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - Context Freed
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - calling delete
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - calling DDCFreeContext
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - end
09:34:17 884 LDAP: SSL_CTX_use_KMO failed. Error stack:
09:34:17 884 PKIAPI: NPKIGetServerKMOInfo called
09:34:17 884 PKIAPI: NPKIGetServerKMOInfo exiting with -1219
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - begin
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - Context Freed
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - calling delete
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - calling DDCFreeContext
09:34:17 884 PKIAPI: libnpkiapi ~NPKI - destructor - end
09:34:17 884 LDAP: SSL_CTX_use_KMO failed. Error stack:
09:34:17 884 LDAP: Disabling TLS services because of configuration failure
09:34:17 884 LDAP: Listener closing TLS port 636
09:34:17 884 LDAP: LDAPURL: ldap://:389
09:34:17 884 LDAP: LDAPURL: ldaps://:636
09:34:17 884 LDAP: LDAPURL: ldap://:389
09:34:17 884 LDAP: LDAPURL: ldaps://:636
09:34:17 884 LDAP: Adding SASL module dependencies
09:34:17 884 LDAP: SASL initialized successfully
09:34:17 884 LDAP: SASL configured successfully
....
----------------------

fiddled around recreated the certificate several times, no chance to get that working.
i think the line PKIAPI: NPKIGetServerKMOInfo exiting with -1219 from trace indicates a
problem with getting the kmo (the object did exist, i checked ..).
see: getServerKMOInfo in https://www.novell.com/documentation/developer/ncsjava/jpki_enu/api/com/novell/security/japi/pki/NPKIAPI.html#getServerKMOInfo(int,%20java.lang.String,%20java.lang.String,%20int,%20byte[][],%20java.lang.Integer,%20java.lang.Integer,%20byte[][],%20java.lang.Integer,%20byte[][])

since the old certificate was named mycompany_myedirectory_LDAPCert and the new one
mycompany_myedirectory_LDAPSCert i supposed this might (out of desparation) be a
parsing error or a too long name. made a new certificate with the same options named
something the lines of 'mycert'. used that for ldap and it worked. made a new certificate
named with exactly the same number of letters as the (originally wanted) name and it worked.
made a new certificate with the name i wanted to have in the first place. and it worked.

i do not understand why it did not work in the first place, any theory is welcome (i
will have to do the same in production, and i'd be interested in every obscure theory 🙂
to avoid multiple attempts to get ldap up and running with a new cert.

thanks, florian

Labels (1)
0 Likes
9 Replies
florianz1 Absent Member.
Absent Member.

Re: ldap: transient SSL_CTX_use_KMO failed. Error stack:

and what i'd be interested in as well, how can i force reloading of the http-stack?
dhostcon.exe on windows does not work correctly (edir 9.0.3), Bug 1052716 was filed for that in 2017.

this still seems not adressed to date (at least not listed in https://support.microfocus.com/kb/doc.php?id=7016794).


PS C:\novell\nds> .\dhostcon.exe 192.168.0.1 unload httpstk
DHost Console for NetIQ eDirectory 9.0.3 (40005.12.)

ERROR-DHOSTCON-FFFFE8A9(-5975): Module "HTTPSTK" is already unloaded
PS C:\novell\nds> .\dhostcon.exe 192.168.0.1 modules
DHost Console for NetIQ eDirectory 9.0.3 (40005.12.)

Module Description
ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄ
DHOST.EXE NetIQ eDirectory Operating Environment Host Process
DCONSERV.DLM NCPX Console Server
DHLOG.DLM DHost Logger
DS.DLM Directory Agent for NetIQ eDirectory
DSLOADER.DLM Loader Service for NetIQ eDirectory
EMBOX.DLM eDirectory Management Tool Box Engine
GAMS.DLM Graded Authentication Management Service
HCONSERV.DLM HTTP Console Server
HTTPSTK.DLM HTTP Protocol Stack
NCPENGINE.DLM NCP Protocol Stack
NDSIMON.DLM iMonitor for NetIQ eDirectory
NDSSNMP.DLM SNMP support for eDirectory
NICIEXTWX64.DLM Server NICI NCP Handlers
NLDAP.DLM eDirectory LDAP Server
NMAS.DLM NetIQ Modular Authentication Service
PKI.DLM NetIQ Certificate Server
SASL.DLM Simple Authentication and Security Layer
SPMDCLNT.DLM spmdclnt
PS C:\novell\nds>


is there another way to restart http-stack or does one need to restart nds?

thanks. florian.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: ldap: transient SSL_CTX_use_KMO failed. Error stack:

It would help us know what else has possibly changed if you could provide
the certificate details in base64-encoded format, so we can compare and
see whatever else may be different.

You mentioned a Subject Alternative Name (SAN) and while I do not think it
is related, I hope it is useful to somebody to find out that when you have
one or more SANs the main Subject field of the certificate is ignored by
properly-coded clients, so be SURE any Subject you want is present in the
SAN list, even if it is also in the Subject list. Also useful is to have
a box's IP address in the SAN list, since internally we often seem to get
to boxes via IP address.

I'm not sure how to reload the HTTP stack within ndsd on windows without a
restart of the ndsd/dhost service, but I use windows so seldom (not at all
in many years) I could easily just not have ever needed to look it up.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
florianz1 Absent Member.
Absent Member.

Re: ldap: transient SSL_CTX_use_KMO failed. Error stack:

thanks, AB.

checked with https://lapo.it/asn1js/ and certutil - seemed ok to me.

working cert:
-----BEGIN CERTIFICATE-----
MIIGHTCCBQWgAwIBAgIkAhwFYsaBUr6gltgoAj/qlP9X9XPJkIZFrLnk3gcMAgIWzpULMA0GCSqG
SIb3DQEBCwUAMC8xETAPBgNVBAoTCEFSWi1UUkVFMRowGAYDVQQLExFPcmdhbml6YXRpb25hbCBD
QTAeFw0xNzA3MTcxNTA0MDBaFw0xOTA3MTcxNTA0MDBaMDExETAPBgNVBAoTCEFSWi1UUkVFMRww
GgYDVQQDExNDODcwQTMwMi5tMjg3LmxvY2FsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA3Lu365uUHf377ven4gzp7/OVPmwk8mFDdowLYvo9foHEvzRfBz+8zAWgKsfnYEoIQ/EvQqka
ZdjbrGU/D93GhC7A2nxkTrSckBwLyCTxyp8dMywsf08XUE2nYJMs3gw22ncGzAav3xkKxwhbYAjs
JAIx737SHQ5sLup6ufqGM9LXW/GQvjOw0Yx0QcEZ6Rgl+Dy9MxPRgVjsbJXK5lJDpfBWdZlmYNck
+n1yTij/Rzan5OUGgU5ZhA6su6bZDpDxdENzSaCLnIq87usNWuRGJIy9S/TG6thbECpdRYwIbgFj
2h46l3cEAmdOiLWlCZYDk/hKaEEmDwWbk4zI3uHw4wIDAQABo4IDHTCCAxkwHQYDVR0OBBYEFNv0
2gICL929yTmBrAp7WokpafDaMB8GA1UdIwQYMBaAFFJfyvwy4FuwmkWBeyWL4jLZDe1pMAsGA1Ud
DwQEAwIFoDA5BgNVHREEMjAwhwQKAgsCghNwX21kc3J2Mi5tMjg3LmxvY2FsghNjODcwYTMwMi5t
Mjg3LmxvY2FsMIIBzAYLYIZIAYb4NwEJBAEEggG7MIIBtwQCAQABAf8THU5vdmVsbCBTZWN1cml0
eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9h
dHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBSKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoC
AWmhGgEBADAIMAYCAQECAQAwCDAGAgEBAgEAAgEAogYCARcBAf+jggEEoFgCAQICAgD/AgEAAw0A
gAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQAC
CH//////////AQEAAgQG8N9IoVgCAQICAgD/AgEAAw0AQAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAw
GDAQAgEAAgh//////////wEBAAIEEf+yajAYMBACAQACCH//////////AQEAAgQR/7Jqok4wTAIB
AgIBAAICAP8DDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADASMBACAQACCH//////////AQEAMBIw
EAIBAAIIf/////////8BAQAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwgakGA1UdHwSBoTCBnjAzoDGg
L4YtaHR0cDovL2FyemNybC5tMjg3LmxvY2FsL0NlcnREYXRhL21ldGFkaXIuY3JsMGegZaBjpGEw
XzEQMA4GA1UEAxMHbWV0YWRpcjEgMB4GA1UEAxMXbWV0YWRpciAtIENvbmZpZ3VyYXRpb24xFjAU
BgNVBAMTDUNSTCBDb250YWluZXIxETAPBgNVBAMTCFNlY3VyaXR5MA0GCSqGSIb3DQEBCwUAA4IB
AQB2rYHo0bzJGjOaUF1Sgs9vfd9H0SjO6welCWwBIp9TVs/lYwxJTQjm+/teHjhC9zdhVuKGUBZx
smrXDq8szXmnHfl2HVytPFyIZzdefhyyCgwmgyPcoZ3hYfU3wQGZ2sMqHa3EOvdV9KH1m8xS0UUF
W5opHyx9r2jsCU32sxRCSJPdSixNp/07M41c6ojoXw9ABIea5+XSWIXemqh1aAkJlr+uTZHs+rIo
LN9goc16YuChKxI2LBGeNHZ3iox4cEqn5gK/yfg1zOGLerCQULUbMKPZVBltfnACjV0BUvwAnxnP
hKxtvNJwErvRNSMldKeVd1WH1DiF95P2XOst6gyl
-----END CERTIFICATE-----

notworking cert:
-----BEGIN CERTIFICATE-----
MIIGITCCBQmgAwIBAgIUDNfygKqBp6vV7CVZwk3GeLmyGAkwDQYJKoZIhvcNAQELBQAwLzERMA8G
A1UEChMIQVJaLVRSRUUxGjAYBgNVBAsTEU9yZ2FuaXphdGlvbmFsIENBMB4XDTE5MDUwMjE0NDQw
MFoXDTIwMDgxMTExMzIwMFowMTERMA8GA1UEChMIQVJaLVRSRUUxHDAaBgNVBAMTE0M4NzBBMzAy
Lm0yODcubG9jYWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCoAGGfyr0lDogUzRQ3
qX6UBGVpjwkuNJjPSMtgLZUvWeBPX8yxQa2Gt2sNftW5FwD2IyErE0P+6k3hezu9QEYSNtTsyrb9
4l1IWRNtG+bcnj1OTlbarr5JxTngZ6/E0Z80EvN8hsYXzVYLX0tAwEijHY+NLY1pv0JCF2vtgNir
Qlf+Hk/E5zcjfrboFeCnaMfT6B8MdV54fmCiww7jywGImNCotanH1bKGiY/7JYiMViL7HUUwNL2w
gF1HANADOgQXI1HYZk/0rSC0umgzxH7RWGwAHkVGp7MWnab7H+0WYSEEphWf0BpBEBL+flhfmRyI
xCr/RPNnmwW2Gl4PHT8JAgMBAAGjggMxMIIDLTAdBgNVHQ4EFgQUoFdgk+4Cd8i1aFICMWTMO+r6
P9wwHwYDVR0jBBgwFoAUUl/K/DLgW7CaRYF7JYviMtkN7WkwCwYDVR0PBAQDAgWgME0GA1UdEQRG
MESCEnBtZHNydjIubTI4Ny5sb2NhbIITcF9tZHNydjIubTI4Ny5sb2NhbIITYzg3MGEzMDIubTI4
Ny5sb2NhbIcECgILAjCCAcwGC2CGSAGG+DcBCQQBBIIBuzCCAbcEAgEAAQH/Ex1Ob3ZlbGwgU2Vj
dXJpdHkgQXR0cmlidXRlKHRtKRZDaHR0cDovL2RldmVsb3Blci5ub3ZlbGwuY29tL3JlcG9zaXRv
cnkvYXR0cmlidXRlcy9jZXJ0YXR0cnNfdjEwLmh0bTCCAUigGgEBADAIMAYCAQECAUYwCDAGAgEB
AgEKAgFpoRoBAQAwCDAGAgEBAgEAMAgwBgIBAQIBAAIBAKIGAgEXAQH/o4IBBKBYAgECAgIA/wIB
AAMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBgwEAIBAAIIf/////////8BAQACBAbw30gwGDAQ
AgEAAgh//////////wEBAAIEBvDfSKFYAgECAgIA/wIBAAMNAEAAAAAAAAAAAAAAAAMJAEAAAAAA
AAAAMBgwEAIBAAIIf/////////8BAQACBBH/smowGDAQAgEAAgh//////////wEBAAIEEf+yaqJO
MEwCAQICAQACAgD/Aw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwEjAQAgEAAgh//////////wEB
ADASMBACAQACCH//////////AQEAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMIGpBgNVHR8EgaEwgZ4w
M6AxoC+GLWh0dHA6Ly9hcnpjcmwubTI4Ny5sb2NhbC9DZXJ0RGF0YS9tZXRhZGlyLmNybDBnoGWg
Y6RhMF8xEDAOBgNVBAMTB21ldGFkaXIxIDAeBgNVBAMTF21ldGFkaXIgLSBDb25maWd1cmF0aW9u
MRYwFAYDVQQDEw1DUkwgQ29udGFpbmVyMREwDwYDVQQDEwhTZWN1cml0eTANBgkqhkiG9w0BAQsF
AAOCAQEAdCCIGqwHo+uWHX31ZrLiCnTwgB3tNjqsSwsaZhiILB1yPrV5OWgoxOjfzuqyvabDFdod
UlixZl2l5pn6mEnhFC8vTpZ8TJu94V9DWvdOpcXuTV526gQSQzqfDMDDV271RQ+IDHiLg1FnjoO/
1vNQJb4FxH0a6cku8orLQ1IuKaYgUpqBMJhBGn4HyUSZZaAy84efJfadZVBRlCrz8NrEqnSbditA
mfRycE97+eFCQESXCONOzpowJlmyDdbsdDHTLfQ8skJt3L3N4VfAFWrEg1mKAvcS9Si7bM71XcD2
CwTemR9V8+4NgRMT//jR1DhqNNC6yxQvo3+gOTiQCbCzRg==
-----END CERTIFICATE-----

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: ldap: transient SSL_CTX_use_KMO failed. Error stack:

These certs are definitely different, bu not in any way that causes me
great pause at this point in time. Other tha nsignatures and hashes
which should change with any changed set of keys or certificates, the only
differences I see are the NotBefore and NotAfter dates (currently either
one is valid, though), and the Subject Alternative Name (SAN) list, though
both look pretty normal, but the "bad" certificate has one more SAN than
the "good" one, though both have a value matching the certificate's Subject.

If I did not know better I would guess this has more to do with how the
certificate exists within eDirectory, or how the application is trying to
use it, as everything else is identical from the issuer through the list
of uses for the certificates.

One interesting thing about eDirectory 9.x is that it REQUIRES a private
key to be exportable, where eDirectory 8.x and earlier did not. This is
the default, I believe, but if you changed that then the ability for
eDirectory to use the certificate is lost, which of course makes no sense
with internal things like LDAPS or HTTPS. Is it possible you had chosen
to NOT let the private key be exportable? A bug early on found this
issue, even though iManager would let you create certs keypairs this way,
and I think now it stops you on eDir 9.x boxes, or at least warns you.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
florianz1 Absent Member.
Absent Member.

Re: ldap: transient SSL_CTX_use_KMO failed. Error stack:

i did make the private key exportable, as i had issues with that in the past: https://forums.novell.com/showthread...45#post2461545

newer imanager versions no longer present this option. thats the fix 🙂

0 Likes
Knowledge Partner
Knowledge Partner

Re: ldap: transient SSL_CTX_use_KMO failed. Error stack:

First cert has:
Common Name: C870A302.m287.local
Subject Alternative Names: IP Address:10.2.11.2, p_mdsrv2.m287.local,
c870a302.m287.local

Second has:
Common Name: C870A302.m287.local

Subject Alternative Names: pmdsrv2.m287.local, p_mdsrv2.m287.local,
c870a302.m287.local, IP Address:10.2.11.2
0 Likes
Knowledge Partner
Knowledge Partner

Re: ldap: transient SSL_CTX_use_KMO failed. Error stack:

> You mentioned a Subject Alternative Name (SAN) and while I do not think it
> is related, I hope it is useful to somebody to find out that when you have
> one or more SANs the main Subject field of the certificate is ignored by
> properly-coded clients, so be SURE any Subject you want is present in the
> SAN list, even if it is also in the Subject list. Also useful is to have


I had not realized that subtle detail. I thought it was looking at
Subject Name. I always wondered, since the format was kind of X.500'y
did it only look at the value of cn=. And I guess your answer is it
prefers the SAN and ignore the subject name.

How interesting.

0 Likes
Knowledge Partner
Knowledge Partner

Re: ldap: transient SSL_CTX_use_KMO failed. Error stack:

florianz;2499842 wrote:
and what i'd be interested in as well, how can i force reloading of the http-stack?
dhostcon.exe on windows does not work correctly (edir 9.0.3), Bug 1052716 was filed for that in 2017.

this still seems not adressed to date (at least not listed in https://support.microfocus.com/kb/doc.php?id=7016794).


PS C:\novell\nds> .\dhostcon.exe 192.168.0.1 unload httpstk
DHost Console for NetIQ eDirectory 9.0.3 (40005.12.)

ERROR-DHOSTCON-FFFFE8A9(-5975): Module "HTTPSTK" is already unloaded
PS C:\novell\nds> .\dhostcon.exe 192.168.0.1 modules
DHost Console for NetIQ eDirectory 9.0.3 (40005.12.)

Module Description
ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄ
DHOST.EXE NetIQ eDirectory Operating Environment Host Process
DCONSERV.DLM NCPX Console Server
DHLOG.DLM DHost Logger
DS.DLM Directory Agent for NetIQ eDirectory
DSLOADER.DLM Loader Service for NetIQ eDirectory
EMBOX.DLM eDirectory Management Tool Box Engine
GAMS.DLM Graded Authentication Management Service
HCONSERV.DLM HTTP Console Server
HTTPSTK.DLM HTTP Protocol Stack
NCPENGINE.DLM NCP Protocol Stack
NDSIMON.DLM iMonitor for NetIQ eDirectory
NDSSNMP.DLM SNMP support for eDirectory
NICIEXTWX64.DLM Server NICI NCP Handlers
NLDAP.DLM eDirectory LDAP Server
NMAS.DLM NetIQ Modular Authentication Service
PKI.DLM NetIQ Certificate Server
SASL.DLM Simple Authentication and Security Layer
SPMDCLNT.DLM spmdclnt
PS C:\novell\nds>


is there another way to restart http-stack or does one need to restart nds?

thanks. florian.


Try unload/load on the ndsimon.dlm module. I think that's what ou need on this.
0 Likes
florianz1 Absent Member.
Absent Member.

Re: ldap: transient SSL_CTX_use_KMO failed. Error stack:

got it.

when the certificate gets created the CN of the ldap-object is a combination of custom display name (of the cert) and the servername (e.g. cn=mycertificate - edirserver1). for whatever reason most certificates created with imanager (i tested different versions) have not one whitespace char, but 2 or three of those between both parts of the CN (e.g. cn=mycertificate - edirserver1).

when choosing the server certificate ldap should use only the first part is presented in the drop-down (e.g. mycertificate). i assume at startup edir tries to locate the object by searching for cn=<name> and adds ' - <servername>', thus not being able to locate the 'real' certificate.

so rc=1219 of GetServerKMOInfo means: 'could not find server certificate'.

florian

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.