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