Hi Daniel, All, just as a follow up for this...
a) I have posted an update for sscep to "fix" the retrieval of a CRL (not perfect but will do the job) b) After almost a day debugging with several test data I am pretty sure that LibSCEP does the "right" job if the correct information was requested. The example data provided by Daniel by PM shows the same "defect" as sscep does, it sends a Issuer/serial request where serial and issuer do not reference a valid certificate. As already announced we are already on a rewrite of this and will back this with a workflow so it will be much easier to work around such broken implementations. best regards Oliver Am 14.10.21 um 14:55 schrieb Daniel Hoffend: > Hi Oliver > > I've some updates. And recreated the PKI to be able to share some parts > of it with you. > > One thing I've stumbled across today was really strange. > > When I do the GetCRL from the Cisco XE Router (or replicate it) the > LibSCEP returns the serial + issuer_dn from the Issuing CA (issuer_dn is > okay, but serial os != issuer_and_serial->serial) > > Now I've tried to replicate the GetCRL Request via sscep and results that > are even more strange. > > 1) Generate CSR > 2) GetCA > -> creates ca.crt-0 (scep-ra), ca.crt-1 (issuing), ca.crt-2 (root) > 3) Enroll > -> create my local.crt, local.key > 4) ./sscep getcrl -v -u <url> -c ca.crt-0 -l local.crt -k local.key -w > ca.crl > (ca.crt-0 works, ca.crt-1/2 doesn't cause openxpki can't find the key) > > Now come the totally strange part. LibSCEP get_getcert_serial and > get_issuer > commands returns the serial (as HEX not DEC) + subject from the scep-ra > > It looks a bit like LibSCEP is working with some handle and not the real > requested serial_and_issuer part. > > -- Update while writing -- > > I've looked into the code of OpenXPKI I found a difference between the > Service SCEP and LibSCEP. And that could be the reason I've encounterd > the previous issues > > LibSCEP: uses scep_handle to find the requested serial/issuer > https://github.com/openxpki/openxpki/blob/develop/core/server/OpenXPKI/Service/LibSCEP/Command/PKIOperation.pm#L162 > > > SCEP: uses a decoded pkcs7 field to retrieve the requested serial > https://github.com/openxpki/openxpki/blob/develop/core/server/OpenXPKI/Service/SCEP/Command/PKIOperation.pm#L226 > > > Could that the be root issue? > > What's the difference between Service LibSCEP and Service SCEP? Are both > fully exchangable? > > -- > best regards, > Daniel > > > > > > > > Am 2021-10-04 14:04, schrieb Oliver Welter: >> Hi Daniel, >> >> well even if it is not commonly used, I want to get it working properly >> on OpenXPKI ;) >> >> Besides using HTTP to get a CRL is not "insecure", as the CRL itself is >> "secure" in terms of integrity and authenticity you will "just" leak >> some information (which indeed can be considered to be a security risk). >> >> I would appreciate if you can send me the inner PKCS7 structure that was >> used by the router to query the CRL so we can examine what was going >> wrong and also use it as a test vector. >> >> best regards >> >> Oliver >> >> Am 04.10.21 um 11:13 schrieb Daniel Hoffend: >>> Hi Oliver, Carlos, >>> >>> thanks for pointing me to the right direction in the LibSCEP.xs code. >>> I was searching within github and the search function was hiding >>> the block from me. Anyway ... >>> >>> The fact that the C-Code is exactly accessing issuer_and_serial -> >>> serial leaves me with questionmarks on my head which part is >>> return the wrong serial. The wrapper, the pkcs7 parser or what. >>> >>> Hmmmmm. According to Oliver the GetCRL feature is rarely used in >>> real production environments, maybe we might wanna skip it too and >>> propably switch to http instead by either setting up a dedicated >>> webserver or reuse the cisco internal webserver for crl delivery >>> to minimize the footprint of servers and services within the >>> unsecure transportation network. >>> >>> I'm happy that we came across this problem in our test environment >>> before we're rolling out the production pki/network. So we still >>> have a chance to do some minor design changes. >>> >>> @Oliver: regarding future tests. It depends, personally I'm more >>> on the server/pki side rather than then cisco guy, but we can I >>> how things are going. >>> >>> I'll see how much time I can spend on digging depper >>> >>> >>> best regards >>> Daniel Hoffend >>> >>> Am 2021-10-03 14:47, schrieb Oliver Welter: >>>> Hi Daniel, Carlos, >>>> >>>> thank you for this indepth analysis of the code. I must admit that we >>>> have never seen the GetCRL feature somewhere in production and we >>>> tested it only with the "sscep" client which seemed to work but I can >>>> remember that we had a similar (likely the exact same) problem during >>>> development some time ago.... >>>> >>>> In case there is really something wrong, I am happy to accept a pull >>>> request for a fix. As we are currently investigating to drop LibSCEP >>>> and replace this with our new PurePerl PKCS7 module, I would not put >>>> too much effort in it, in case it is not super urgent to get this >>>> working. In any case I would appreciate Daniels help in testing the >>>> new implementation with your Cisco gear ;) >>>> >>>> best regards >>>> >>>> Oliver >>>> >>>> >>>> Am 01.10.21 um 22:18 schrieb Carlos Velasco: >>>>> Hi Daniel, >>>>> >>>>> I was curious about this, as I work mostly with Cisco and I didn't >>>>> know you could get a CRL check through SCEP. So I took a look at the >>>>> codes. >>>>> >>>>> I think the missing part you are looking for is in "LibSCEP.xs" (C >>>>> wrapper for perl). >>>>> === >>>>> SV * >>>>> get_getcert_serial(pkiMessage) >>>>> Crypt::LibSCEP pkiMessage >>>>> PREINIT: >>>>> char *ret = NULL; >>>>> CODE: >>>>> ret = ""; >>>>> if(pkiMessage->issuer_and_serial != NULL) { >>>>> ret = i2s_ASN1_INTEGER(NULL, >>>>> pkiMessage->issuer_and_serial->serial); >>>>> } >>>>> RETVAL = newSVpv(ret, 0); >>>>> OUTPUT: >>>>> RETVAL >>>>> === >>>>> >>>>> I think this is called from "Service/LibSCEP/Command/PKIOperation.pm" >>>>> === >>>>> sub __find_cert_issuer_serial : PRIVATE { >>>>> >>>>> my $self = shift; >>>>> my $arg_ref = shift; >>>>> >>>>> my $token = $arg_ref->{TOKEN}; >>>>> my $scep_handle = $arg_ref->{SCEP_HANDLE}; >>>>> >>>>> my $requested_serial_dec = $token->command({ >>>>> COMMAND => 'get_getcert_serial', >>>>> SCEP_HANDLE => $scep_handle, >>>>> }); >>>>> ... >>>>> === >>>>> >>>>> And this is called from "__send_crl" in same file: >>>>> === >>>>> =head2 __send_crl >>>>> >>>>> Create the response for the GetCRL request by extracting the >>>>> issuer and >>>>> serial from the request. As we do not support scoped CRLs yet it is >>>>> sufficient to check the issuer dn but to catch situations where the >>>>> issuer dn >>>>> is used over multiple generations we search for both. >>>>> >>>>> =cut >>>>> >>>>> sub __send_crl : PRIVATE { >>>>> >>>>> my $self = shift; >>>>> my $arg_ref = shift; >>>>> my $scep_handle = $arg_ref->{SCEP_HANDLE}; >>>>> my $token = $arg_ref->{TOKEN}; >>>>> >>>>> my $cert_result = $self->__find_cert_issuer_serial( $arg_ref ); >>>>> === >>>>> >>>>> But I don't see any error in the logic here. >>>>> >>>>> I *suppose* the C wrapper is taking the serial in the request >>>>> through: >>>>> i2s_ASN1_INTEGER(NULL, pkiMessage->issuer_and_serial->serial); >>>>> >>>>> Currently I cannot test, but I would look into this serial. >>>>> >>>>> Regards, >>>>> Carlos Velasco >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenXPKI-users mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/openxpki-users >>>>> >>> > -- Protect your environment - close windows and adopt a penguin! _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
