Re: extrange problem with ldapsearch

["Pablo J Royo" <royop@tb-solutions.com>]

Thank for your answer, Kurt.

I have tried with 2.2.26 and the problem is the same.
Here is the output (-LLL option in ldapsearch) when it works:

filter: cn=CRL2001
requesting: certificateRevocationList
dn: cn=CRL2001,ou=FNMT Clase 2 CA,o=FNMT,c=ES
certificateRevocationList::
MIIEdDCCA90CAQEwDQYJKoZIhvcNAQEFBQAwNjELMAkGA1UEBh

MCRVMxDTALBgNVBAoTBEZOTVQxGDAWBgNVBAsTD0ZOTVQgQ2xhc2UgMiBDQRcNMDUwNjAzMDUzMj
M

wWhcNMDUwNjA0MDUzMjMwWjCCAt0wIwIEPII/ABcNMDUwNTI0MTEzNDIxWjAMMAoGA1UdFQQDCgE
E

MCMCBDyCPwgXDTA1MDUyNzEwNTU0MVowDDAKBgNVHRUEAwoBBDAjAgQ8gj86Fw0wNTA1MjQxMjA3
M

TBaMAwwCgYDVR0VBAMKAQQwIwIEPII/PhcNMDUwNTI0MTMyMTI3WjAMMAoGA1UdFQQDCgEAMD0CB
D

yCP0oXDTA1MDUyMzEyMTg1NlowJjAKBgNVHRUEAwoBATAYBgNVHRgEERgPMjAwNTA1MjMxMjE2NT
d

aMD0CBDyCP1YXDTA1MDUyNDExMDEzNFowJjAKBgNVHRUEAwoBATAYBgNVHRgEERgPMjAwNTA1MjQ
x

MDQ5MDZaMCMCBDyCP18XDTA1MDUyMzEyMDY1NFowDDAKBgNVHRUEAwoBBDAjAgQ8gj9jFw0wNTA1
M

jQxMjQzMjZaMAwwCgYDVR0VBAMKAQQwIwIEPII/excNMDUwNTI0MTMyMTQ1WjAMMAoGA1UdFQQDC
g

EAMCMCBDyCP6IXDTA1MDUyNDEzMjEyN1owDDAKBgNVHRUEAwoBADA9AgQ8gj/BFw0wNTA1MzAxMj
E

wMjZaMCYwCgYDVR0VBAMKAQEwGAYDVR0YBBEYDzIwMDUwNTMwMTIwNTQ0WjAjAgQ8gj/SFw0wNTA
1

MjQyMzEwMTFaMAwwCgYDVR0VBAMKAQAwPQIEPII/5xcNMDUwNTI2MTMzMzIzWjAmMAoGA1UdFQQD
C

gEBMBgGA1UdGAQRGA8yMDA1MDUyNjEzMzE0MFowIwIEPIJAFxcNMDUwNTI2MTgzNTA0WjAMMAoGA
1

UdFQQDCgEAMCMCBDyCQRIXDTA1MDUyNTE0MTQzNVowDDAKBgNVHRUEAwoBADAjAgQ8gkGcFw0wNT
A

1MjYxMTA3NDVaMAwwCgYDVR0VBAMKAQQwIwIEPIJBohcNMDUwNjAyMTgzMjI5WjAMMAoGA1UdFQQ
D

CgEAoIGRMIGOMAoGA1UdFAQDAgEkMB8GA1UdIwQYMBaAFECadkSXdAfErBTLHo1POkV8MNdhMF8G
A

1UdHAEB/wRVMFOgTqBMpEowSDELMAkGA1UEBhMCRVMxDTALBgNVBAoTBEZOTVQxGDAWBgNVBAsTD
0

ZOTVQgQ2xhc2UgMiBDQTEQMA4GA1UEAxMHQ1JMMjAwMYEB/zANBgkqhkiG9w0BAQUFAAOBgQBQq7
d

pBmc4K/tx6JVuaOSdHpZwnVOQYL6o2ruhcxqPasKgAOO7mHuj1S0VdLF2eS6qm4QdkBbclNTBjjR
i

VdmNNPf5Wk18rK0V3Hp+iKT0MRlP71KXwu2Yp7qgHVMmpXdokgDJCCfL+f/BBZ3w9XXog5/+g04G
j
 75XK/X5pGv5fA==

and when it doesn´t work:

filter: cn=CRL2002
requesting: certificateRevocationList
dn: cn=CRL2002,ou=FNMT Clase 2 CA,o=FNMT,c=ES
certificateRevocationList:: MIIDcTCCAtoCAQEwDQYJKoZIhvcNAQEFBQ==

Is the same if I use -t option to dump to a temporary file.That final ==
chars are the usual padding for end of B64 stream.
I supplied the CRLs on my last message because if you check its DER format
you will see they have a NULL char at byte 25. I don´t know it if has
something to do with this error, but I´ve been using OpenLDAP for CRL
retrieval for years with no problem, so I suspect this could be a bug.

Regards
Pablo

----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: "Pablo J Royo" <royop@tb-solutions.com>
Cc: <openldap-software@OpenLDAP.org>
Sent: Friday, June 03, 2005 2:47 AM
Subject: Re: extrange problem with ldapsearch


> ldapsearch(1) provides LDIF as output, and as what you provide
> is not LDIF, it not clear what ldapsearch(1) is actually producing.
> I suspect a case of garbage-in/garbage-out where the data, though
> it may be valid, wasn't provided in the correct form and his
> is not provided in correct form.  Unfornuately, OpenLDAP 2.0
> didn't conformance to each values proper syntax.  2.0 is,
> of course, historic.  You should consider upgrading to at
> least the latest stable release (presently 2.2.26).
>
> (The remainder of this post is actually not specific to
> OpenLDAP Software.  Follow questions to anything in the
> remainder should likely be directed to the general LDAP
> mailing list at <ldap@umich.edu>.)
>
> I note the proper format for a CRL in LDIF would be:
>
> certificateRevocationList;binary:: base64-encoded-value
>
> where base64-encoded-value is the Base64 encoding of the
> DER encoding of the X.509 CRL.  See RFC 2849 for details on
> the LDIF format, and RFC 2256/2252 for details on the proper
> LDAP encoding of CRLs.
>
> Kurt
>
>
> At 10:57 AM 6/2/2005, Pablo J Royo wrote:
> >Hello
> >
> >I have a curious problem with OpenLDAP when I download a CRL from a LDAP
using ldapsearch. I can download some CRLs but no others, althought using
other software (Softerra) I can also download problematic CRLs. When the
error happens, CRLs are cut to 25 bytes.
> >The problem happens with last version of OpenLdap, but also with an old
2.0.11 version.
> >I´m sure CRLs are correct, because they are from an official
organization. (well, I think so...)
> >
> >This is the line I use to test the problem:
> >
> >ldapsearch -v -t -x -P 2 -D 'cn=XXXXX' -w XXXXX -b
"OU=blah,OU=blah..." -h ldap.host.com -p 389 'cn=CRL2001'
certificateRevocationList
> >
> >This is the CRL (which seems Ok) that gives problems (obtained with
Softerra browser):
> >
> >-----BEGIN X509 CRL-----
> >MIIDcTCCAtoCAQEwDQYJKoZIhvcNAQEFBQAwNjELMAkGA1UEBhMCRVMxDTALBgNV
> >BAoTBEZOTVQxGDAWBgNVBAsTD0ZOTVQgQ2xhc2UgMiBDQRcNMDUwNjAyMTQxOTU4
> >WhcNMDUwNjAzMTQxOTU4WjCCAdowPQIEPIJCARcNMDUwNTMwMTIxMjQxWjAmMAoG
> >A1UdFQQDCgEBMBgGA1UdGAQRGA8yMDA1MDUzMDEyMTAyOFowPQIEPIJCJxcNMDUw
> >NTI0MTAwODQ3WjAmMAoGA1UdFQQDCgEBMBgGA1UdGAQRGA8yMDA1MDUyNDEwMDQ1
> >NVowPQIEPIJCPRcNMDUwNTMxMDcxOTM1WjAmMAoGA1UdFQQDCgEBMBgGA1UdGAQR
> >GA8yMDA1MDUzMTA3MTUwMlowIwIEPIJCgxcNMDUwNTI1MDczMDAwWjAMMAoGA1Ud
> >FQQDCgEEMD0CBDyCQuMXDTA1MDUzMDA3MjExN1owJjAKBgNVHRUEAwoBATAYBgNV
> >HRgEERgPMjAwNTA1MzAwNzE4NDhaMCMCBDyCQ2cXDTA1MDUyNjA3MzcwNlowDDAK
> >BgNVHRUEAwoBBDAjAgQ8gkQUFw0wNTA1MzAxMTQ4MTNaMAwwCgYDVR0VBAMKAQQw
> >IwIEPIJEeBcNMDUwNTMwMTE0NTQzWjAMMAoGA1UdFQQDCgEEMCMCBDyCRIoXDTA1
> >MDUyNTA5MjE1MlowDDAKBgNVHRUEAwoBBDAjAgQ8gkSiFw0wNTA1MjQxMDQyMzRa
> >MAwwCgYDVR0VBAMKAQSggZEwgY4wCgYDVR0UBAMCARwwHwYDVR0jBBgwFoAUQJp2
> >RJd0B8SsFMsejU86RXww12EwXwYDVR0cAQH/BFUwU6BOoEykSjBIMQswCQYDVQQG
> >EwJFUzENMAsGA1UEChMERk5NVDEYMBYGA1UECxMPRk5NVCBDbGFzZSAyIENBMRAw
> >DgYDVQQDEwdDUkwyMDAygQH/MA0GCSqGSIb3DQEBBQUAA4GBAIN9d0Wq5a7megaK
> >583xOuokYQ7AVNFiYbqmem2Kctwh1s4ySvFVoBm6iNMZozYdEFh4NIT9NeTZStl1
> >p008F6arcT7bVhfQtxn5Wskr9fRgrvWen6i14SIPrRaYkirA4BVYbHI4A8mbG7Be
> >/RfyM6g1OHicKsFxnOxyS575ggjZ
> >-----END X509 CRL-----
> >
> >and this is a correctly downloaded CRL with ldapsearch
> >
> >-----BEGIN X509 CRL-----
> >MIIE2DCCBEECAQEwDQYJKoZIhvcNAQEFBQAwNjELMAkGA1UEBhMCRVMxDTALBgNV
> >BAoTBEZOTVQxGDAWBgNVBAsTD0ZOTVQgQ2xhc2UgMiBDQRcNMDUwNjAyMDgwNjM2
> >WhcNMDUwNjAzMDgwNjM2WjCCA0EwPQIEPIGSQRcNMDUwNTI0MTkzNTMwWjAmMAoG
> >A1UdFQQDCgEBMBgGA1UdGAQRGA8yMDA1MDUyNDE5MzAyNFowIwIEPIGSRBcNMDUw
> >NTE2MDk0NjQyWjAMMAoGA1UdFQQDCgEEMCMCBDyBklIXDTA1MDUwOTE1MTkyNVow
> >DDAKBgNVHRUEAwoBBDAjAgQ8gZJzFw0wNTA1MDkxNTQwNDVaMAwwCgYDVR0VBAMK
> >AQQwIwIEPIGShxcNMDUwNTEwMTUwMzI3WjAMMAoGA1UdFQQDCgEAMCMCBDyBktUX
> >DTA1MDUxMzIwMjg0MFowDDAKBgNVHRUEAwoBBDA9AgQ8gZLYFw0wNTA1MTAwODIy
> >MzJaMCYwCgYDVR0VBAMKAQEwGAYDVR0YBBEYDzIwMDUwNTEwMDgxNzQyWjA9AgQ8
> >gZMoFw0wNTA1MTEwODI3NDdaMCYwCgYDVR0VBAMKAQEwGAYDVR0YBBEYDzIwMDUw
> >NTExMDgyMTM1WjAjAgQ8gZMrFw0wNTA1MjQxMzU1MTVaMAwwCgYDVR0VBAMKAQQw
> >IwIEPIGTyBcNMDUwNTEyMTMwMjMwWjAMMAoGA1UdFQQDCgEEMCMCBDyBk9YXDTA1
> >MDUyNTEzMDUyMFowDDAKBgNVHRUEAwoBBDA9AgQ8gZPsFw0wNTA1MTExMDM2MjJa
> >MCYwCgYDVR0VBAMKAQEwGAYDVR0YBBEYDzIwMDUwNTExMTAzNDMwWjA9AgQ8gZPz
> >Fw0wNTA1MTExMDM5MDhaMCYwCgYDVR0VBAMKAQEwGAYDVR0YBBEYDzIwMDUwNTEx
> >MTAzNzAxWjAjAgQ8gZQ4Fw0wNTA1MTYwOTQ3MzZaMAwwCgYDVR0VBAMKAQQwIwIE
> >PIGUUxcNMDUwNTEzMTk1NzU0WjAMMAoGA1UdFQQDCgEEMCMCBDyBlJAXDTA1MDUy
> >NDE5NTA0NlowDDAKBgNVHRUEAwoBBDAjAgQ8gZSgFw0wNTA1MDkyMDEyMzlaMAww
> >CgYDVR0VBAMKAQQwIwIEPIGU4xcNMDUwNTE4MjAyNDEwWjAMMAoGA1UdFQQDCgEE
> >MCMCBDyBlOgXDTA1MDUwOTE5MzUzOVowDDAKBgNVHRUEAwoBAKCBkTCBjjAKBgNV
> >HRQEAwIBQzAfBgNVHSMEGDAWgBRAmnZEl3QHxKwUyx6NTzpFfDDXYTBfBgNVHRwB
> >Af8EVTBToE6gTKRKMEgxCzAJBgNVBAYTAkVTMQ0wCwYDVQQKEwRGTk1UMRgwFgYD
> >VQQLEw9GTk1UIENsYXNlIDIgQ0ExEDAOBgNVBAMTB0NSTDE5NDKBAf8wDQYJKoZI
> >hvcNAQEFBQADgYEAArUm2IlqcoJdunZuvAVbX4dTDqWz1RU5ppBGozzxNNM6glWv
> >zGJ0F06D5jcEdBHQZesDL4h9fKtQkrm7NWqQI4f9wQr1BM3GRTKDTMCgAt0P2Xje
> >dtSO8lsO0j7UOaFTh5r5mZ+VuslBwRb6oGi/l+23KU7rsOB61aJQZmPqsZI=
> >-----END X509 CRL-----
> >
> >The two CRLs are correct. The problem is with its retrieval from the
LDAP.
> >
> >Does somebody knows what happens?
>
>