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
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
