Unable to verify LDAP CRL

2024-04-30 Thread Tot 191919
Hello, I am unable to validate an LDAP based CRL for any of my certificates. If 
I download the CRL from LDAP, decode it from base64, and then run it through 
OpenSSL, it works without issue. When I run an strace, it appears that openssl 
is looking for the certificate on the local filesystem, and my server never 
attempts to make a network connection to the LDAP server during the 
verification. I have tried running with the -verbose flag; however, that does 
not add any additional details. My certificate is a self-signed root cert just 
for the purposes of testing. Can you please advise?

Running on RHEL

cat /etc/redhat-release; uname -r
Red Hat Enterprise Linux release 8.8 (Ootpa)
4.18.0-477.36.1.el8_8.x86_64


OpenSSL Version:

OpenSSL 1.1.1k  FIPS 25 Mar 2021


Command resulting in error:

openssl verify -crl_check -CAfile test_root.pem test_root.pem
CN = -Root-XXX-GP
error 3 at 0 depth lookup: unable to get certificate CRL
error test_root.pem: verification failed


Downloading from LDAP and running file through OpenSSL:

ldapsearch -o ldif-wrap=no -x -H ldap://my-ldap.example.net:389 -b 
"cn=CA1,ou=crl,dc=example,dc=net" "certificateRevocationList;binary" | sed -n 
'/^certificateRevocationList;binary:: /{s/^certificateRevocationList;binary:: 
//p}' > crl.base64
base64 -d crl.base64 > crl.der
openssl crl -inform DER -text -noout -in crl.der
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = , CN = -CRL-GP
Last Update: Apr 27 05:31:19 2024 GMT
Next Update: May 27 05:31:19 2024 GMT
Revoked Certificates:
Serial Number: 56D5B8C0EB3E0C162E9171A70D455B7D6541F702
Revocation Date: Apr 27 05:31:19 2024 GMT
Signature Algorithm: sha256WithRSAEncryption
 38:eb:d6:b7:2e:11:66:f6:b2:b9:18:88:7b:fd:7c:4a:be:fd:
 30:cd:85:7c:4d:77:8b:9b:bc:58:32:38:da:f1:1a:ea:af:a9:
 fa:83:2c:39:95:e3:42:f7:40:f3:31:df:41:12:94:cb:7d:be:
 8b:e7:74:db:e1:2f:61:23:cc:db:ca:2e:d8:05:49:22:f3:bb:
 d9:03:21:8f:b5:8f:c4:9b:6d:ec:db:0e:69:93:d3:fc:5d:0f:
 6a:9f:0a:55:cc:a4:ec:3d:60:79:e3:44:ea:32:5f:1f:5d:bf:
 56:36:96:69:1e:e1:d0:7e:c1:f8:79:ba:55:83:a0:77:fc:6a:
 15:43:61:c8:53:ac:98:59:d9:86:19:43:f8:43:15:ba:57:b8:
 34:6e:a8:ba:5c:2f:0c:e3:b1:0c:c0:d4:be:f6:46:4e:10:57:
 06:1c:93:f3:e8:88:0f:d5:7b:68:2f:f1:4c:29:f3:7a:ee:98:
 04:90:84:ff:ee:bf:6f:3e:7d:b7:79:c2:af:3a:b5:53:86:92:
 5c:c8:4f:44:7c:55:61:e9:ba:6f:ac:85:1a:55:93:8f:05:eb:
 f3:dc:bc:be:4a:35:cc:37:1a:47:02:29:a9:32:ee:7e:1c:ec:
 9e:bc:3c:36:03:cc:1b:0c:5e:56:3b:a9:eb:db:f2:1d:89:39:
 d1:e0:05:86


Here is my certificate:

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
42:93:9c:9d:71:47:5e:6e:63:ab:39:97:58:c6:44:21:c0:43:2d:18
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = -Root-XX-GP
Validity
Not Before: Apr 27 09:36:58 2024 GMT
Not After : Apr 25 09:46:58 2034 GMT
Subject: CN = -Root-XX-GP
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:

Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
5C:83:F3:7A:B9:09:FD:D2:C3:A8:A1:60:E6:F2:40:A7:B5:16:3A:C4
X509v3 Authority Key Identifier:

keyid:5C:83:F3:7A:B9:09:FD:D2:C3:A8:A1:60:E6:F2:40:A7:B5:16:3A:C4

X509v3 Subject Alternative Name:
DNS:-Root-XX-GP
X509v3 CRL Distribution Points:

Full Name:
  
URI:ldap://my-ldap.example.net/cn=CA1,ou=crl,dc=example,dc=net?certificateRevocationList;binary

Signature Algorithm: sha256WithRSAEncryption
 d7:49:b2:2b:e6:f7:95:5a:38:48:cf:36:0e:b6:ca:20:01:c7:
 0e:d3:62:17:94:ce:44:76:99:06:7f:d5:91:95:2c:a5:42:3f:
 46:af:7a:38:85:2f:17:ba:db:50:45:c5:c0:0e:97:7a:e8:d7:
 4f:55:bf:6e:84:85:be:fd:a6:82:a2:c8:60:bb:d5:b8:74:fb:
 cf:07:a4:5b:ec:8b:f5:a2:d4:4a:a4:5c:35:ad:80:19:cf:ed:
 36:23:8d:4a:94:cc:5f:f4:c0:82:44:5e:6a:52:50:c8:b0:9c:
 3b:1f:a4:4c:9e:f8:27:e9:29:be:c4:2c:fc:20:a5:48:21:47:
 03:ef:9e:f7:84:61:48:d2:3a:f5:f6:bd:a5:f1:e0:8b:56:08:
 5f:1b:fa:9a:da:8d:9a:13:5b:0b:7d:64:46:ff:23:56:7e:5d:
 07:31:32:02:75:52:5f:a8:f2:1f:41:c0:7f:6b:46:dd:bb:02:
 47:61:61:01:a8:dc:c6:f1:4a:93:07:05:04:e7:bd:c5:53:2f:
 04:1e:0f:9d:83:7f:d0:75:62:fc:0c:11:fe:2a:a5:fb:47:b5:
 84:93:ef:0e:23:5b:e3:62:72:28:c4:4e:8c:85:13:fe:7e:42:
 15:03:c6:9a:39:fb:b7:8a:df:84:c9:15:89:fc:f3:1e:6e:c9:

RE: Open SSL 1.1.1 and Vxworks 5.4.2 - Query on Entropy source

2024-04-30 Thread Prithvi Raj R (Nokia) via openssl-users
Users,

An update here: See that we have OPENSSL_RAND_SEED_OS  defined on our VxWorks 
based system. Would it be a trusted entropy source ? The default for VxWorks 
seems to be OPENSSL_RAND_SEED_NONE.

Thanks,
Prithvi
From: Prithvi Raj R (Nokia)
Sent: Tuesday, April 30, 2024 12:47 AM
To: openssl-users@openssl.org
Subject: Open SSL 1.1.1 and Vxworks 5.4.2 - Query on Entropy source

Hi Users,

A beginner on cryptography and Open SSL here.

First query - On our VxWorks 5.4.2 based system with Open SSL 1.1.1, I would 
like to know what entropy source would be used by RAND_priv_bytes() to generate 
random numbers. Does Vxworks not use an OS based entropy source ?  I see so in 
the openssl link: 
https://mta.openssl.org/pipermail/openssl-users/2020-March/012087.html.
In our implementation, we have the OPENSSL_RAND_SEED_NONE macro definition 
commented in the opensslconf.h file. What would be the default entropy source 
then if OS based sources are not used ? Which Open SSL config file/compile 
parameter can help me zero in on the correct entropy source being used ?  
Wanted to know if the source is a trusted one or not. See that 
rand_drbg_get_entropy is being used (no parent drbg ;_rand_pool_acquire_entropy 
is used with entropy factor 2 being set) and entropy available is greater than 
0.

Second query - Please confirm if the following are valid:

  1.  Understand the Entropy size by default is 256 bits.
  2.  Understand that RAND_priv_bytes() is cryptographically secure (depends on 
the entropy source again ?)

Thanks,
Prithvi