0 votes
by (790 points)
edited by

This is a follow-up question to:
Rebex HTTPS Legacy exception: Primitive explicit node encountered

Hello Lukas, thanks for the fast response!

We have see a different behavior on two different devices, both using Version R5.4 Legacy Edition on the .NET Compact Framework 3.5:

On device A the exception is thrown with the code I provided (assuming the certificate engine is CertificateEngine.Default, because not defined anywhere).
It is still thrown after setting the certificate engine to CertificateEngine.Internal, as described in the Knowledge Base article.

On device B the exception is NOT thrown with the code I provided (assuming the certificate engine is CertificateEngine.Default).
It is ONLY thrown after setting the certificate engine to CertificateEngine.Internal.

What’s the background here?

Using CertificateChain.Validate(…) in the event handler, we cannot only define CertificateEngine, but also CertificateChainEngine as CurrentUser or LocalMachine.

Does this additional property have any influence regarding the exception (on this legacy platform)?

Applies to: Rebex TLS

1 Answer

0 votes
by (72.7k points)

Hello,

The CertificateEngine.Internal uses our custom certificate validator to validate certificate chain and to check revocation status of its certificates. The error is related to the CRL parser (part of the revocation status check), which means the error will always arise when you explicitly use CertificateEngine.Internal (note: if you use ValidationOptions.SkipRevocationCheck the error will not be thrown because the CRL parsing routine will be skipped).

If you use CertificateEngine.Default, the certificate chain (and revocation status) is validated by native certificate validator at first. However, our custom validator is used automatically on devices where native validator failed - for example on devices with lack of SHA-2 support.

This means, that device A was not able to validate certificate chain using the native validator. In such case, our custom validator was used and failed during CRL parsing.

On device B the native validator was able to validate the certificate chain, so our custom validator was not used and the error was not thrown (or the CRL was not parsed for example due to usage of the ValidationOptions.SkipRevocationCheck).

The CertificateChainEngine is some extra thing here. The idea is:
all certificates are validated by the globally set CertificateEngine, but you can validate particular chains using your preferred engine by specifying the CertificateChainEngine argument.

Example of use:
You can set CertificateEngine.Internal to validate all "unknown" certificates by custom validator to be able to log the validation process in very details.
And you can use chain.Validate(..., CertificateChainEngine.CurrentUser) to validate "well-known" certificates by native validator to make the validation as fast as possible without need to reset global CertificateEngine.

...