can't specify empty username/password to ldap server

[yoneyajp]

I did this

I'm using curl to download CRL for x.509 certificates like follows.

$ curl-8.20.0 -u : 'ldap://ldap.example.com/o=xxx,c=xxx?certificateRevocationList' >CRL.ldif

This method work fine with curl-8.20.0 or prior (except for early curl-8.19.0), but does not curl-8.21.0.

$ curl-8.21.0 -u : 'ldap://ldap.example.com/o=xxx,c=xxx?certificateRevocationList' >CRL.ldif
curl: (38) LDAP local: bind via ldap_win_bind 資格情報が無効です <-- Invalid credentials

I also tried below, but does not work as well.

$ curl-8.21.0 'ldap://:@ldap.example.com/o=xxx,c=xxx?certificateRevocationList' >CRL.ldif
curl: (38) LDAP local: bind via ldap_win_bind 資格情報が無効です <-- Invalid credentials

I expected the following

I want to specify empty username/password to ldap server using curl.

curl/libcurl version

curl 8.21.0 (x86_64-w64-mingw32) libcurl/8.21.0 LibreSSL/4.3.2 zlib/1.3.1.zlib-ng brotli/1.2.0 zstd/1.5.7 WinIDN libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.69.0 ngtcp2/1.23.0 nghttp3/1.16.0 WinLDAP
Release-Date: 2026-06-24

operating system

Windows 11 Pro 25H2

[dfandrich]

What does an empty username/password do with WinLDAP? Does it (did it) use Kerberos authentication?

[yoneyajp]

It does basic authentication.
#22179 is another my report, but it shows basic authentication is used for CRL downloading.

[dfandrich]

So, the server expects it to authenticate, but with no username and no password? And it treats that differently than no authentication at all? I don't know what the spec say, but that definitely seems pretty weird.

[yoneyajp]

x.509 certificate CRL published by public CA is usually open to the public, so LDAP server doesn't need authentication, that is, no username and no password.

Below is what I did with previous curl. (Actual usage)
$ curl -u : -o - 'ldap://ldap.actalis.it/cn%3dActalis%20Server%20Authentication%20CA,ou%3dCertification%20Service%20Provider,o%3dActalis%20S.p.A.,c%3dIT?certificateRevocationList' >actalis.ldif

Below is probably equivalent method using ldapsearch. (it works but not handy)
$ ldapsearch -x -H 'ldap://ldap.actalis.it/' -b 'cn=Actalis Server Authentication CA,ou=Certification Service Provider,o=Actalis S.p.A.,c=IT' certificateRevocationList >actalis.ldif

[dfandrich]

That exact command ("Actual usage") works fine for me on 8.21.0 on OpenLDAP. It also works fine dropping the -u option. There must be something specific to WinLDAP going on there.

[dfandrich]

Is ldap.actalis.it the same server as the original report was filed on (ldap.example.com)? Because, that doesn't need a login for me so dropping the -u should work. If not, then it sounds like WinLDAP is trying to authenticate somehow even without the username/password option being set, when it shouldn't. Is it trying to do Kerberos under the hood when it shouldn't be?

[yoneyajp]

Is ldap.actalis.it the same server as the original report was filed on (ldap.example.com)?

Yes, it is.

Because, that doesn't need a login for me so dropping the -u should work.

I think so, because as I mentioned in previous comment, ldapsearch usage does not specify username/password.

If not, then it sounds like WinLDAP is trying to authenticate somehow even without the username/password option being set, when it shouldn't. Is it trying to do Kerberos under the hood when it shouldn't be?

I think so, too. However, curl-8.20.0 is still working with -u : but curl-8.21.0 isn't. I believe some workaround be existing for WinLDAP, and if there, I'd like to know. My apologizes that I'm not investigating source code changes around ldap authentication yet due to time constaints.

[jay]

Ref: https://github.com/curl/curl/blob/curl-8_21_0/docs/internals/CREDENTIALS.md
Ref: https://github.com/curl/curl/blob/curl-8_21_0/lib/creds.h#L73-L84

Bisected to 8f71d0f which added the creds struct to manage credentials. @icing

The doc says all credentials values empty means it is equivalent to NULL? Does this mean strings specifically or like what if refcount is 1 then creds isn't NULL? Like how is it NULL if it's not null. Anyway though it looks like for ldap credentials are no longer passed through if they're empty:

curl/lib/ldap.c

Lines 274 to 277 in 68720b4

	const char *user = Curl_creds_has_user(data->state.creds) ?
	data->state.creds->user : NULL;
	const char *passwd = Curl_creds_has_passwd(data->state.creds) ?
	data->state.creds->passwd : NULL;

The creds has* macros do not pass on return true for empty values, so what is happening here is Curl_creds_has_user is returning NULL false etc, so NULL is passed to the bind function which then terminates the connection. In other words,

before: rc = ldap_win_bind(data, server, "", "");

click to expand empty auth seen in wireshark

Lightweight Directory Access Protocol
    LDAPMessage bindRequest(1) "<ROOT>" simple
        messageID: 1
        protocolOp: bindRequest (0)
            bindRequest
                version: 3
                name: 
                authentication: simple (0)
                    simple: 
        [Response In: 9]

after: rc = ldap_win_bind(data, server, NULL, NULL);

Although the connection is made, Windows doesn't treat that as an empty auth and immediately terminates the connection. (edit: If curl is built with Windows SSPI support then a NULL username and pass results in attempting to use the current user's Windows credentials to login)

I think what we can do here is use Curl_creds_user instead of Curl_creds_has_user to allow the empty username and the same thing for passwd. (edit: I've since changed my proposal to get closer to the old behavior, refer to the pr)

Please try #22196

[yoneyajp]

Please try #22196

I really appreciate your hardwork.
I tried curl-8.21.0_2 (released today), but it didn't work still, but the error message was changed. Whether '-u :' exists didn't matter.

$ curl --versioni
curl 8.21.0 (x86_64-w64-mingw32) libcurl/8.21.0 LibreSSL/4.3.2 zlib/1.3.1.zlib-ng brotli/1.2.0 zstd/1.5.7 WinIDN libpsl/0.22.0 libssh2/1.11.1 nghttp2/1.69.0 ngtcp2/1.24.0 nghttp3/1.17.0 WinLDAP
...

$ curl -u : -o - 'ldap://ldap.actalis.it/cn%3dActalis%20Server%20Authentication%20CA,ou%3dCertification%20Service%20Provider,o%3dActalis%20S.p.A.,c%3dIT?certificateRevocationList' >actalis.ldif
curl: (38) LDAP local: bind via ldap_win_bind 利用できません <-- can't use

$ curl -o - 'ldap://ldap.actalis.it/cn%3dActalis%20Server%20Authentication%20CA,ou%3dCertification%20Service%20Provider,o%3dActalis%20S.p.A.,c%3dIT?certificateRevocationList' >actalis.ldif
curl: (38) LDAP local: bind via ldap_win_bind 利用できません <-- can't use

In the same environment, curl-8.20.0 works with '-u :' option, while not works without '-u :' option.

$ curl-8.20.0 -o - 'ldap://ldap.actalis.it/cn%3dActalis%20Server%20Authentication%20CA,ou%3dCertification%20Service%20Provider,o%3dActalis%20S.p.A.,c%3dIT?certificateRevocationList' >actalis.ldif
curl: (38) LDAP local: bind via ldap_win_bind 利用できません <-- can't use

[jay]

I tried curl-8.21.0_2 (released today), but it didn't work still, but the error message was changed.

The error message "利用できません" translates to "Not Available" in English. I think maybe the server was not available at the time. Can you try again?