openca-ocspd Mailing List for OpenCA

Open Source PKI solutions

Brought to you by: giova23, madwolf, openca

openca-ocspd — Discussions about OCSP Responder

You can subscribe to this list here.

2010	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct (2)	Nov (10)	Dec (8)
2011	Jan (4)	Feb (17)	Mar (16)	Apr (1)	May (5)	Jun (7)	Jul	Aug	Sep	Oct	Nov	Dec
2012	Jan	Feb (5)	Mar	Apr (4)	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2013	Jan (18)	Feb	Mar	Apr (6)	May	Jun	Jul (3)	Aug (5)	Sep (12)	Oct (6)	Nov (6)	Dec (4)
2014	Jan	Feb (4)	Mar	Apr	May (10)	Jun	Jul (4)	Aug (8)	Sep (5)	Oct	Nov (16)	Dec (3)
2015	Jan	Feb	Mar (12)	Apr (40)	May (51)	Jun (8)	Jul (5)	Aug	Sep (6)	Oct	Nov (2)	Dec
2016	Jan	Feb	Mar (1)	Apr	May	Jun	Jul (3)	Aug (1)	Sep	Oct (1)	Nov	Dec
2017	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct (5)	Nov (6)	Dec
2018	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct (5)	Nov	Dec
2019	Jan (2)	Feb	Mar	Apr (63)	May (2)	Jun	Jul (2)	Aug (4)	Sep	Oct	Nov	Dec
2022	Jan	Feb	Mar	Apr	May (3)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2024	Jan	Feb	Mar	Apr	May	Jun (1)	Jul (1)	Aug	Sep	Oct	Nov	Dec

Flat | Threaded

1 2 3 .. 17 > >> (Page 1 of 17)

[Openca-ocspd] Not being able to build the library

From: Romina R. <rom...@mz...> - 2024-07-31 08:05:16

Hi, I hope this message finds you well.

I have a problem regarding starting the use of the tool and libpki. downloading the latest release version, I could not run ./configure. However, I downgraded to another version and now I can configure. But using make I have these errors that I cannot fix. can you please help me with them?

/usr/bin/ld: pki_tool-pki-tool.o: undefined reference to symbol 'EVP_sha256@@OPENSSL_3.0.0'
/usr/bin/ld: /lib/x86_64-linux-gnu/libcrypto.so.3: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:670: pki-tool] Error 1
make[2]: Leaving directory '/etc/libpki/src/tools'
make[1]: *** [Makefile:964: all-recursive] Error 1
make[1]: Leaving directory '/etc/libpki/src'
make: *** [Makefile:674: all-recursive] Error 1

Kind regards,
Romina

[Openca-ocspd] Segmentation fault from ocspd-genreq.sh

From: 藤本康 <yas...@ip...> - 2024-06-25 23:20:00

Hi, All.

I have a trouble to run ocspd-genreq.sh after I installed openca-ocspd using openca-ocspd-3.1.2.tar.gz.
If some one give me a point where I have to check, it will help


While I am trying to setup RA on the RHEL 8.9, I have download openca-ocspd-3.1.2.tar.gz, configured it and ran
/opt/ocspd/bin/ocspd-genreq.sh.

I got the following message


[root@ttca01 openca-ocspd-3.1.2]# time /opt/ocspd/bin/ocspd-genreq.sh



OCSP Key and Certificate Request generation Tool

(c) 2009 by Massimiliano Pala and OpenCA Labs

    All Rights Reserved



Please Enter the Server's Subject (eg., CN=OCSP Server, O=OpenCA, C=US):

XXXXXXXXXXXXXXXXXXXXXXXXXXXX

Please Enter the Algorithm (default: RSA-SHA256):



Please Enter the Key Size (default: 2048):





Parameters Summary:

- prefix ................: /opt/ocspd

- token Name ............: ocspServerToken

- subject ...............:XXXXXXXXXXXXXXXXXXXXXXXXXXXX

- algorithm .............: RSA-SHA256

- key size ..............: 2048 bits



This tool uses the pki-tool from libpki. The configuration of the

token can be found in '/opt/ocspd/etc/ocspd/pki/token.d'



[ Use a password when prompted if you want the server key to be encrypted ]



/opt/ocspd/bin/ocspd-genreq.sh: line 61: 3130768 Segmentation fault      (core dumped) pki-tool genreq -config "$prefix/etc/ocspd/pki" -outkey "$prefix/etc/ocspd/private/key.pem" -newkey -bits $bits -subject "$subject" -algor "$algor" -out "$prefix/etc/ocspd/req.pem" -batch

ERROR, can not complete task. Please check write permissions for target(s)

[most probably you need administrator privileges to continue].





real    2m34.598s

user    0m0.074s

sys     0m0.005s

[root@ttca01 openca-ocspd-3.1.2]#


“libpki” had been downloaded from https://sourceforge.net/projects/openca/files/libpki/releases/v0.9.0/sources/libpki-0.9.0.tar.gz/download

I have run pki-tool command only. The result seems to be same.

[root@ttra01 libpki-0.9.0]# pki-tool genreq -config /opt/ocspd/etc/ocspd/pki -outkey /opt/ocspd/etc/ocspd/private/key.pem -newkey -bits 2048 -subject 'xxxxxxxxxxxxxxxxx' -algor RSA-SHA256 -out /opt/ocspd/etc/ocspd/req.pem -batch

Segmentation fault (core dumped)

[root@ttra01 libpki-0.9.0]#




I have tried gdb expecting I get any more info, but I don’t know what I have to do with this.



[root@ttra01 libpki-0.9.0]# gdb pki-tool

GNU gdb (GDB) Red Hat Enterprise Linux 8.2-20.el8

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

http://www.gnu.org/software/gdb/bugs/.

Find the GDB manual and other documentation resources online at:

    http://www.gnu.org/software/gdb/documentation/.



For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from pki-tool...done.

(gdb) run genreq -config /opt/ocspd/etc/ocspd/pki -outkey /opt/ocspd/etc/ocspd/private/key.pem -newkey -bits 2048 -subject 'xxxxxxxxxxxxxx"' -algor RSA-SHA256 -out /opt/ocspd/etc/ocspd/req.pem -batch

Starting program: /usr/bin/pki-tool genreq -config /opt/ocspd/etc/ocspd/pki -outkey /opt/ocspd/etc/ocspd/private/key.pem -newkey -bits 2048 -subject 'xxxxxxxxxxxxxxx"' -algor RSA-SHA256 -out /opt/ocspd/etc/ocspd/req.pem -batch

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.

0x00007ffff6f53178 in x509_name_ex_i2d () from /usr/lib64/libcrypto.so.1.1

Missing separate debuginfos, use: yum debuginfo-install cyrus-sasl-lib-2.1.27-6.el8_5.x86_64 glibc-2.28-236.el8.7.x86_64 keyutils-libs-1.5.10-9.el8.x86_64 krb5-libs-1.18.2-25.el8_8.x86_64 libcom_err-1.45.6-5.el8.x86_64 libselinux-2.9-8.el8.x86_64 libxcrypt-4.1.1-6.el8.x86_64 libxml2-2.9.7-16.el8_8.1.x86_64 openldap-2.4.46-18.el8.x86_64 openssl-libs-1.1.1k-9.el8_7.x86_64 pcre2-10.32-3.el8_6.x86_64 xz-libs-5.2.4-4.el8_6.x86_64 zlib-1.2.11-25.el8.x86_64

(gdb) where

#0  0x00007ffff6f53178 in x509_name_ex_i2d () from /usr/lib64/libcrypto.so.1.1

#1  0x00007ffff6de67ac in ASN1_item_ex_i2d () from /usr/lib64/libcrypto.so.1.1

#2  0x00007ffff6de6c29 in asn1_template_ex_i2d () from /usr/lib64/libcrypto.so.1.1

#3  0x00007ffff6de66b7 in ASN1_item_ex_i2d () from /usr/lib64/libcrypto.so.1.1

#4  0x00007ffff6de69f7 in asn1_item_flags_i2d () from /usr/lib64/libcrypto.so.1.1

#5  0x00007ffff7b7ae5b in PKI_X509_VALUE_get_tbs_asn1 (v=<optimized out>, type=<optimized out>) at pki_x509.c:529

#6  0x00007ffff7b8c908 in PKI_X509_sign (x=x@entry=0x628e70, digest=digest@entry=0x7ffff7209d00, key=key@entry=0x62ef50) at hsm_main.c:527

#7  0x00007ffff7b84e1c in PKI_X509_REQ_new (k=0x62ef50, subj_s=subj_s@entry=0x7fffffffe485 "C=JP, O=KEK, OU=CRC, CN=\"KEK GRID Certificate Authority\"",

    req_cnf=req_cnf@entry=0x0, oids=<optimized out>, digest=0x7ffff7209d00, hsm=<optimized out>) at pki_x509_req.c:205

#8  0x00007ffff7b76bd1 in PKI_TOKEN_new_req (profile_s=0x0, subject=0x7fffffffe485 "C=JP, O=KEK, OU=CRC, CN=\"KEK GRID Certificate Authority\"", tk=0x62a4c0)

    at token.c:2254

#9  PKI_TOKEN_new_req (tk=tk@entry=0x62a4c0, subject=subject@entry=0x7fffffffe485 "C=JP, O=KEK, OU=CRC, CN=\"KEK GRID Certificate Authority\"",

    profile_s=profile_s@entry=0x0) at token.c:2211

#10 0x0000000000402ef2 in main (argc=<optimized out>, argv=<optimized out>) at pki-tool.c:906

(gdb)



If anyone gave me a point where I have to start investigation, it will help me

Thankyou

Yasushi Fujimoto

[Openca-ocspd] Attempting to build from source - libpki ok, but openca-ocspd failing

From: ohaya <oh...@ya...> - 2022-05-12 04:45:24

Hi,

Since I am kind of stuck with using the 2 RPMs to try to install the OCSP responder, I decided to try to build from source.

I downloaded the openca-ocspd-master.zip and the libpki-master.zip,

I can configure, make, and make install libpki.  However when I try to build openca-ocspd using:

./configure --prefix=/apps/oracle/ocspd --with-libpki-prefix=/apps/oracle/libpki

That step works, but when I try to compile, I am getting this:

 make
Making all in src
make[1]: Entering directory `/tmp/jl/openca-ocspd-master/src'
Making all in ocspd
make[2]: Entering directory `/tmp/jl/openca-ocspd-master/src/ocspd'
gcc -DHAVE_CONFIG_H -I. -I../../src/ocspd/includes  -I.  -I/apps/oracle/libpki/include -DENABLE_ECDSA=1 -I/usr/include/libxml2   -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT ocspd-ocspd.o -MD -MP -MF .deps/ocspd-ocspd.Tpo -c -o ocspd-ocspd.o `test -f 'ocspd.c' || echo './'`ocspd.c
mv -f .deps/ocspd-ocspd.Tpo .deps/ocspd-ocspd.Po
gcc -DHAVE_CONFIG_H -I. -I../../src/ocspd/includes  -I.  -I/apps/oracle/libpki/include -DENABLE_ECDSA=1 -I/usr/include/libxml2   -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT ocspd-core.o -MD -MP -MF .deps/ocspd-core.Tpo -c -o ocspd-core.o `test -f 'core.c' || echo './'`core.c
core.c: In function ‘start_threaded_server’:
core.c:55:13: error: ‘PKI_TOKEN_STATUS_KEYPAIR_ERR’ undeclared (first use in this function)
   if (rv & (PKI_TOKEN_STATUS_KEYPAIR_ERR |
             ^
compilation terminated due to -Wfatal-errors.
make[2]: *** [ocspd-core.o] Error 1
make[2]: Leaving directory `/tmp/jl/openca-ocspd-master/src/ocspd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/jl/openca-ocspd-master/src'
make: *** [all-recursive] Error 1

If anyone is here, can you tell me what is causing the above error?

Thanks,
Jim

[Openca-ocspd] Problem installing OCSP responder RPM (libpki.so.89()(64bit) is needed by openca-ocspd-3.1.2-1.el7.x86_64)!

From: ohaya <oh...@ya...> - 2022-05-12 02:51:45

Hi,

I am trying to install the OCSP Responder on a Redhat 7 machine and am having the following problem:

[root@ip-192-168-114-98 jl]# rpm -ivh libpki-0.9.0-1.el7.x86_64.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:libpki-0.9.0-1.el7               ################################# [100%]


[root@ip-192-168-114-98 jl]# rpm -ivh openca-ocspd-3.1.2-1.el7.x86_64.rpm
error: Failed dependencies:
        libpki.so.89()(64bit) is needed by openca-ocspd-3.1.2-1.el7.x86_64

I've done some searching and found a couple of msgs with the same error, but no solutions.

Please advise.

Thanks,
Jim

[Openca-ocspd] OCSP Responder 3.1.2 and LibPKI 0.90 RPMs status

From: ohaya <oh...@ya...> - 2022-05-11 14:40:15

Hi,

It has been awhile since posting!

We are preparing to re-deploy OCSPD to some new RHEL7 machines and I wanted to check if the OCSP Responder v3.1.2 and LibPKI 0.90 RPM downloads below are the correct current ones and are stable?  

openca-ocspd-3.1.2-1.el7.x86_64.rpm
Size: 51 Kb - Downloads: 2418
[Sha1: 43e453fbb8d06e7f1a924d9e49d25cb2074edbdb]

libpki-0.9.0-1.el7.x86_64.rpm
Size: 339 Kb - Downloads: 1562
[Sha1: 4671e10121141a4537ca1ddaddd776509f9e88db]

Thanks,
Jim

Re: [Openca-ocspd] Question about OpenCA OCSPD response for "Revoked-Superceded"?

From: <oh...@ya...> - 2019-08-06 20:18:55

 Hi,
FYI, please ignore the information below, and also the other email about the other similar situation where I thought that some CRL entries might not be in OCSPD's database from the import.

It looks like I had generated the list of serial numbers that was I was using to drive a load test using one set of CRL files, but the actual OCSPD was using a different set of CRL files.
Sorry!
Jim

    On Monday, August 5, 2019, 9:33:11 PM UTC, oh...@ya... <oh...@ya...> wrote:  
 
 Hi,
I have testing against one of our CRLs, and in there, we have a cert serial 2FB227.  Here's the output from the "openssl crl" for that serial number:
    Serial Number: 2FB227
        Revocation Date: Jul 23 13:43:55 2019 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Superseded
            Invalidity Date:
                Jul 23 13:43:39 2019 GMT

However, when I run an "openssl ocspd" (send a request) test, against OpenCA OCSPD with this CRL, I am getting this:
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 9FC23C79C5BC28FDCD3EC6E5201AECCD200DABE4
          Issuer Key Hash: 5B91C64436F228F2F8CFB2C2C8CA6349619B200A
          Serial Number: 2FB227
    Request Extensions:
        OCSP Nonce:
            04109ED8FB9BFBBC1900A6B08972EBC308F7
Response verify OK
0x2FB227: good
        This Update: Aug  5 21:27:45 2019 GMT
        Next Update: Aug  5 21:32:45 2019 GMT



So, it looks like, from the CRL, the cert was Revoked, because it was "superceded", and then when I run an OCSP request for the serial number, OpenCA OCSPD is sending an OCSP response that does not indicate that the cert was revoked?
I am not that familiar with the RFC's (and with the "Superceded" reason) but is that a "correct" OCSP response for that revoked entry in the CRL file?
Shouldn't OpenCA OCSPD be sending an OCSP response that indicates that the certificate with that serial number has been Revoked?
Thanks,Jim

Re: [Openca-ocspd] Question about OpenCA OCSPD response for "Revoked-Superceded"?

From: <oh...@ya...> - 2019-08-06 14:54:18

 Hi,
I just realized that the OCSP responses with:
Response verify OK
0x17FF15: good
        This Update: Aug  6 14:18:41 2019 GMT
        Next Update: Aug  6 14:23:41 2019 GMT

are the same as when OCSPD cannot find the serial number??

So it seems like some of the entries that are in the CRL file are NOT in the OCSPD database, i.e., when I do an OCSP request for 17FF15, OCSPD does not have that entry in its database???

Jim



    On Tuesday, August 6, 2019, 2:25:33 PM UTC, oh...@ya... <oh...@ya...> wrote:  
 
 Hi,

This is similar to a case I mentioned in my previout post, but this time it is for a entry in the CRL that is "Key Compromise".

I have testing against one of our CRLs, and in there, we have a cert serial 17FF15.  Here's the output from the "openssl crl" for that serial number:

    Serial Number: 17FF15
        Revocation Date: Sep 27 16:41:12 2018 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Key Compromise


However, when I run an "openssl ocspd" (send a request) test, against OpenCA OCSPD with this CRL, I am getting this:

OOCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 9FC23C79C5BC28FDCD3EC6E5201AECCD200DABE4
          Issuer Key Hash: 5B91C64436F228F2F8CFB2C2C8CA6349619B200A
          Serial Number: 17FF15
    Request Extensions:
        OCSP Nonce:
            0410C4C258A539DD8568B18DD47058D02E75
Response verify OK
0x17FF15: good
        This Update: Aug  6 14:18:41 2019 GMT
        Next Update: Aug  6 14:23:41 2019 GMT




So, it looks like, from the CRL, the cert was Revoked, because it was "Key Compromise", and then when I run an OCSP request for the serial number, OpenCA OCSPD is sending an OCSP response that does not indicate that the cert was revoked?

Again, I am not that familiar with the RFC's but is that a "correct" OCSP response for that revoked entry in the CRL file?

Shouldn't OpenCA OCSPD be sending an OCSP response that indicates that the certificate with that serial number has been Revoked?

For instance, here is the CRL entry vs. OCSP response for another serial number, 17FF16:
    Serial Number: 17FF16
        Revocation Date: Oct 29 16:55:42 2018 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Affiliation Changed
            Invalidity Date:
                Oct 29 16:49:18 2018 GMT




OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 9FC23C79C5BC28FDCD3EC6E5201AECCD200DABE4
          Issuer Key Hash: 5B91C64436F228F2F8CFB2C2C8CA6349619B200A
          Serial Number: 17FF16
    Request Extensions:
        OCSP Nonce:
            041070807FF2981BD8E943724399B93011E7
Response verify OK
0x17FF16: revoked
        This Update: Aug  6 14:23:01 2019 GMT
        Next Update: Aug  6 14:28:01 2019 GMT
        Reason: affiliationChanged
        Revocation Time: Oct 29 16:55:42 2018 GMT


Notice the OCSP response for the 17FF16 serial number has:
0x17FF16: revoked
and:
        Reason: affiliationChanged
        Revocation Time: Oct 29 16:55:42 2018 GMT


Thanks,
Jim

[Openca-ocspd] Question about OpenCA OCSPD response for "Revoked-Superceded"?

From: <oh...@ya...> - 2019-08-06 14:25:47

Hi,

This is similar to a case I mentioned in my previout post, but this time it is for a entry in the CRL that is "Key Compromise".

I have testing against one of our CRLs, and in there, we have a cert serial 17FF15.  Here's the output from the "openssl crl" for that serial number:

    Serial Number: 17FF15
        Revocation Date: Sep 27 16:41:12 2018 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Key Compromise


However, when I run an "openssl ocspd" (send a request) test, against OpenCA OCSPD with this CRL, I am getting this:

OOCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 9FC23C79C5BC28FDCD3EC6E5201AECCD200DABE4
          Issuer Key Hash: 5B91C64436F228F2F8CFB2C2C8CA6349619B200A
          Serial Number: 17FF15
    Request Extensions:
        OCSP Nonce:
            0410C4C258A539DD8568B18DD47058D02E75
Response verify OK
0x17FF15: good
        This Update: Aug  6 14:18:41 2019 GMT
        Next Update: Aug  6 14:23:41 2019 GMT




So, it looks like, from the CRL, the cert was Revoked, because it was "Key Compromise", and then when I run an OCSP request for the serial number, OpenCA OCSPD is sending an OCSP response that does not indicate that the cert was revoked?

Again, I am not that familiar with the RFC's but is that a "correct" OCSP response for that revoked entry in the CRL file?

Shouldn't OpenCA OCSPD be sending an OCSP response that indicates that the certificate with that serial number has been Revoked?

For instance, here is the CRL entry vs. OCSP response for another serial number, 17FF16:
    Serial Number: 17FF16
        Revocation Date: Oct 29 16:55:42 2018 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Affiliation Changed
            Invalidity Date:
                Oct 29 16:49:18 2018 GMT




OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 9FC23C79C5BC28FDCD3EC6E5201AECCD200DABE4
          Issuer Key Hash: 5B91C64436F228F2F8CFB2C2C8CA6349619B200A
          Serial Number: 17FF16
    Request Extensions:
        OCSP Nonce:
            041070807FF2981BD8E943724399B93011E7
Response verify OK
0x17FF16: revoked
        This Update: Aug  6 14:23:01 2019 GMT
        Next Update: Aug  6 14:28:01 2019 GMT
        Reason: affiliationChanged
        Revocation Time: Oct 29 16:55:42 2018 GMT


Notice the OCSP response for the 17FF16 serial number has:
0x17FF16: revoked
and:
        Reason: affiliationChanged
        Revocation Time: Oct 29 16:55:42 2018 GMT


Thanks,
Jim

[Openca-ocspd] Question about OpenCA OCSPD response for "Revoked-Superceded"?

From: <oh...@ya...> - 2019-08-05 21:33:18

Hi,
I have testing against one of our CRLs, and in there, we have a cert serial 2FB227.  Here's the output from the "openssl crl" for that serial number:
    Serial Number: 2FB227
        Revocation Date: Jul 23 13:43:55 2019 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Superseded
            Invalidity Date:
                Jul 23 13:43:39 2019 GMT

However, when I run an "openssl ocspd" (send a request) test, against OpenCA OCSPD with this CRL, I am getting this:
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 9FC23C79C5BC28FDCD3EC6E5201AECCD200DABE4
          Issuer Key Hash: 5B91C64436F228F2F8CFB2C2C8CA6349619B200A
          Serial Number: 2FB227
    Request Extensions:
        OCSP Nonce:
            04109ED8FB9BFBBC1900A6B08972EBC308F7
Response verify OK
0x2FB227: good
        This Update: Aug  5 21:27:45 2019 GMT
        Next Update: Aug  5 21:32:45 2019 GMT



So, it looks like, from the CRL, the cert was Revoked, because it was "superceded", and then when I run an OCSP request for the serial number, OpenCA OCSPD is sending an OCSP response that does not indicate that the cert was revoked?
I am not that familiar with the RFC's (and with the "Superceded" reason) but is that a "correct" OCSP response for that revoked entry in the CRL file?
Shouldn't OpenCA OCSPD be sending an OCSP response that indicates that the certificate with that serial number has been Revoked?
Thanks,Jim

Re: [Openca-ocspd] Will putting CRLs into LDAP server reduce OCSPD memory usage?

From: Dr. P. <ma...@op...> - 2019-07-21 15:52:53

Hi Jim,

sorry it took me so much time to reply - I admit I missed your message 
:D For adding a support for DB lookup instead of Memory lookup, the 
effort should be not that much. The way I would architect the project 
would be to add support for the specific DB (in LibPKI Pg and MySQL are 
already supported in the URL interface, however I would not suggest to 
query the database through that interface as it is not optimized for 
speed :D), then I would:

  * Upon CRL loading, I would add a function that takes the single
    entries and put them in the database (and maybe remove the entries
    that are expired - sort of cleanup) and then remove the CRL from
    memory (freeing the memory)
  * Repeat for all the CRLs you want to serve

This might work but you have to be sure you are not updating the DB from 
different instances of the sevice (i.e., there must be a master that 
updates the DB while all the other instances only perform lookup 
operations in the DB).

Possibly, the process that updates the DB could be a separate one (not 
necessarily the OCSPD), while the OCSPD would only perform queries to 
build the responses.

Does this make sense ? Were you thinking about a different type of 
architecture ?

Cheers,
Max


On 7/11/19 9:47 AM, oh...@ya... wrote:
> Hi,
>
> Sorry that it's been awhile since your message below.
>
> We *MAY* be able to provide support for adding the DB option, but, if 
> it is not too much trouble, can you give a high-level description of 
> what would be done?  I am still pushing for it here, but I am not 100% 
> sure yet.
>
> Also, would the modifications be in Java?  Or in C/C++?
>
> Thanks,
> Jim
>
>
>
> On Sunday, May 26, 2019, 11:30:31 PM UTC, Dr. Pala 
> <ma...@op...> wrote:
>
>
> Hi Jim,
>
> interesting issue - something I have not considered (memory usage). 
> Unfortunately, the memory usage will not be different because, in the 
> end, after one of the supported/specific transport protocol is used 
> (i.e., LDAP, HTTP, HTTPS, MySQL, PgSQL, etc.) the CRL is then parsed 
> and entries are created based on the entries in the CRL.
>
> One solution to your problem, maybe, would be to sacrifice the speed 
> of response for the possibility to instantiate OCSPDs in small 
> containters/VMs. My assumption is that disk-space is not an issue.
>
> We could think about modifying the OCSPD to work off a small DB4 or 
> similar... this would allow us to create entries in the DB (filesystem 
> entries instead of memory entries). This might require additional time 
> at CRL reload, but the memory usage would be practically constant with 
> the growing of CRLs.
>
> We have been working recently to make sure LibPKI works well with 
> OpenSSL 1.1.+ branches (and add support for CMS in the same context), 
> and the next update I was thinking was related to two different things:
>
>   * Adding a simple Cache mechanism so that the same answer can be
>     cached for its validity period (or up to 80% of its validity
>     period). This would improve the speed for high-frequency
>     certificates' checks
>   * Adding support for OCSPv2 (and DNS distribution end-points). This
>     is something we have been working for a while and would like to
>     standardize at some point. The main idea is to provide responses
>     for "ranges" of certificates instead of for each of the issued
>     certificates. This would provide smaller overhead when large
>     chunks of the issued certs space are not revoked. For revoked
>     entries, there is no much optimization we can do since you need
>     the full revocation data there.
>
> I guess we can add the low-memory architecture as another enhancement, 
> but I am not sure I have the bandwidth right now to work on that - 
> would you like to work on that together and provide some initial 
> thoughts / code ?
>
> Cheers,
> Max
>
> On 5/24/19 1:00 PM, o haya via Openca-ocspd wrote:
> Hi,
>
> I had asked this question awhile ago, but no one responded, so I would 
> like to ask again.
>
> We currently use OCSPD with multiple CRLs (from different CAs).  Some 
> of these CRLs are quite large, and so the OCSPD memory usage is quite 
> large.
>
> However, we have some scenarios where we have machines with only much 
> smaller memory, but we would still like to use OCSPD and with the same 
> CRLs.
>
> All of our machines include an LDAP server, and from the docs, it 
> seems like OCSPD can work with CRLs in LDAP servers, so we were 
> wondering if we made our own tool to import the CRL contents into the 
> LDAP server, and configured OCSPD to use the CRLs in the LDAP server, 
> do you think/know if the overall memory usage would be reduced, 
> compared to our current configuration?
>
> I understand that the memory usage of the LDAP server, when populated 
> with the CRLs, MIGHT be the same, and if so, we'd end up in a 
> "zero-sum" situation, but I wanted to check what you all thought?  Has 
> anyone used OCSPD with the CRL information in an LDAP?
>
> Thanks,
> Jim
>
>
> _______________________________________________
> Openca-ocspd mailing list
> Ope...@li...  <mailto:Ope...@li...>
> https://lists.sourceforge.net/lists/listinfo/openca-ocspd
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
> _______________________________________________
> Openca-ocspd mailing list
> Ope...@li... 
> <mailto:Ope...@li...>
> https://lists.sourceforge.net/lists/listinfo/openca-ocspd
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

Re: [Openca-ocspd] Will putting CRLs into LDAP server reduce OCSPD memory usage?

From: <oh...@ya...> - 2019-07-11 13:47:55

Attachments: ocipkcnmcjkfmbjc.png

 Hi,
Sorry that it's been awhile since your message below.  

We *MAY* be able to provide support for adding the DB option, but, if it is not too much trouble, can you give a high-level description of what would be done?  I am still pushing for it here, but I am not 100% sure yet.

Also, would the modifications be in Java?  Or in C/C++?
Thanks,Jim



    On Sunday, May 26, 2019, 11:30:31 PM UTC, Dr. Pala <ma...@op...> wrote:  
 
  
Hi Jim,
 
interesting issue - something I have not considered (memory usage). Unfortunately, the memory usage will not be different because, in the end, after one of the supported/specific transport protocol is used (i.e., LDAP, HTTP, HTTPS, MySQL, PgSQL, etc.) the CRL is then parsed and entries are created based on the entries in the CRL.
 
One solution to your problem, maybe, would be to sacrifice the speed of response for the possibility to instantiate OCSPDs in small containters/VMs. My assumption is that disk-space is not an issue.
 
We could think about modifying the OCSPD to work off a small DB4 or similar... this would allow us to create entries in the DB (filesystem entries instead of memory entries). This might require additional time at CRL reload, but the memory usage would be practically constant with the growing of CRLs.
 
We have been working recently to make sure LibPKI works well with OpenSSL 1.1.+ branches (and add support for CMS in the same context), and the next update I was thinking was related to two different things:
    
   - Adding a simple Cache mechanism so that the same answer can be cached for its validity period (or up to 80% of its validity period). This would improve the speed for high-frequency certificates' checks
   - Adding support for OCSPv2 (and DNS distribution end-points). This is something we have been working for a while and would like to standardize at some point. The main idea is to provide responses for "ranges" of certificates instead of for each of the issued certificates. This would provide smaller overhead when large chunks of the issued certs space are not revoked. For revoked entries, there is no much optimization we can do since you need the full revocation data there.
 
I guess we can add the low-memory architecture as another enhancement, but I am not sure I have the bandwidth right now to work on that - would you like to work on that together and provide some initial thoughts / code ?
 
Cheers,
 Max
 
 
 On 5/24/19 1:00 PM, o haya via Openca-ocspd wrote:
  
 
 Hi, 
  I had asked this question awhile ago, but no one responded, so I would like to ask again. 
  We currently use OCSPD with multiple CRLs (from different CAs).  Some of these CRLs are quite large, and so the OCSPD memory usage is quite large. 
  However, we have some scenarios where we have machines with only much smaller memory, but we would still like to use OCSPD and with the same CRLs.  
  
  All of our machines include an LDAP server, and from the docs, it seems like OCSPD can work with CRLs in LDAP servers, so we were wondering if we made our own tool to import the CRL contents into the LDAP server, and configured OCSPD to use the CRLs in the LDAP server, do you think/know if the overall memory usage would be reduced, compared to our current configuration? 
  I understand that the memory usage of the LDAP server, when populated with the CRLs, MIGHT be the same, and if so, we'd end up in a "zero-sum" situation, but I wanted to check what you all thought?  Has anyone used OCSPD with the CRL information in an LDAP?  
  
  Thanks, Jim
   
  
  _______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
 -- 
  Best Regards,  Massimiliano Pala, Ph.D.
 OpenCA Labs Director
  
   _______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd

Re: [Openca-ocspd] Will putting CRLs into LDAP server reduce OCSPD memory usage?

From: Dr. P. <ma...@op...> - 2019-05-26 23:30:22

Hi Jim,

interesting issue - something I have not considered (memory usage). 
Unfortunately, the memory usage will not be different because, in the 
end, after one of the supported/specific transport protocol is used 
(i.e., LDAP, HTTP, HTTPS, MySQL, PgSQL, etc.) the CRL is then parsed and 
entries are created based on the entries in the CRL.

One solution to your problem, maybe, would be to sacrifice the speed of 
response for the possibility to instantiate OCSPDs in small 
containters/VMs. My assumption is that disk-space is not an issue.

We could think about modifying the OCSPD to work off a small DB4 or 
similar... this would allow us to create entries in the DB (filesystem 
entries instead of memory entries). This might require additional time 
at CRL reload, but the memory usage would be practically constant with 
the growing of CRLs.

We have been working recently to make sure LibPKI works well with 
OpenSSL 1.1.+ branches (and add support for CMS in the same context), 
and the next update I was thinking was related to two different things:

  * Adding a simple Cache mechanism so that the same answer can be
    cached for its validity period (or up to 80% of its validity
    period). This would improve the speed for high-frequency
    certificates' checks
  * Adding support for OCSPv2 (and DNS distribution end-points). This is
    something we have been working for a while and would like to
    standardize at some point. The main idea is to provide responses for
    "ranges" of certificates instead of for each of the issued
    certificates. This would provide smaller overhead when large chunks
    of the issued certs space are not revoked. For revoked entries,
    there is no much optimization we can do since you need the full
    revocation data there.

I guess we can add the low-memory architecture as another enhancement, 
but I am not sure I have the bandwidth right now to work on that - would 
you like to work on that together and provide some initial thoughts / code ?

Cheers,
Max

On 5/24/19 1:00 PM, o haya via Openca-ocspd wrote:
> Hi,
>
> I had asked this question awhile ago, but no one responded, so I would 
> like to ask again.
>
> We currently use OCSPD with multiple CRLs (from different CAs).  Some 
> of these CRLs are quite large, and so the OCSPD memory usage is quite 
> large.
>
> However, we have some scenarios where we have machines with only much 
> smaller memory, but we would still like to use OCSPD and with the same 
> CRLs.
>
> All of our machines include an LDAP server, and from the docs, it 
> seems like OCSPD can work with CRLs in LDAP servers, so we were 
> wondering if we made our own tool to import the CRL contents into the 
> LDAP server, and configured OCSPD to use the CRLs in the LDAP server, 
> do you think/know if the overall memory usage would be reduced, 
> compared to our current configuration?
>
> I understand that the memory usage of the LDAP server, when populated 
> with the CRLs, MIGHT be the same, and if so, we'd end up in a 
> "zero-sum" situation, but I wanted to check what you all thought?  Has 
> anyone used OCSPD with the CRL information in an LDAP?
>
> Thanks,
> Jim
>
>
> _______________________________________________
> Openca-ocspd mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openca-ocspd
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

[Openca-ocspd] Will putting CRLs into LDAP server reduce OCSPD memory usage?

From: o h. <oh...@ya...> - 2019-05-24 19:00:28

Hi,
I had asked this question awhile ago, but no one responded, so I would like to ask again.
We currently use OCSPD with multiple CRLs (from different CAs).  Some of these CRLs are quite large, and so the OCSPD memory usage is quite large.
However, we have some scenarios where we have machines with only much smaller memory, but we would still like to use OCSPD and with the same CRLs.  

All of our machines include an LDAP server, and from the docs, it seems like OCSPD can work with CRLs in LDAP servers, so we were wondering if we made our own tool to import the CRL contents into the LDAP server, and configured OCSPD to use the CRLs in the LDAP server, do you think/know if the overall memory usage would be reduced, compared to our current configuration?
I understand that the memory usage of the LDAP server, when populated with the CRLs, MIGHT be the same, and if so, we'd end up in a "zero-sum" situation, but I wanted to check what you all thought?  Has anyone used OCSPD with the CRL information in an LDAP?  

Thanks,Jim