EldoS | Feel safer!

Software components for data protection, secure storage and transfer

CRL not verified (revisited)

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
#35744
Posted: 01/28/2016 06:39:54
by Eugene Mayevski (EldoS Corp.)

One of certificates in the chain references the CRL via LDAP. You can ignore the validation errors in your code, or you must provide an LDAP retriever. To ignore errors please set

Code
MandatoryCRLCheck = false
MandatoryOCSPCheck = false
MandatoryRevocationCheck = false


Please note that ignoring retrieval errors will lower security of the operations.


Sincerely yours
Eugene Mayevski
#35747
Posted: 01/28/2016 08:41:15
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

Hi Eugene
Quote
One of certificates in the chain references the CRL via LDAP

How could I know which certificate (from two in the chain, signer's and CA's) makes trouble?

Quote
You can ignore the validation errors in your code


If I set MandatoryRevocationCheck to false document signature is less valid as CRL is then not embedded.
Quote

The selected certificate is considered valid because it does not appear in a Certificate Revocation List (CRL) obtained on-line.

The CRL was signed by "FINA" on 2015/12/31 10:04:06 +01'00' and is valid until 2017/12/31 10:04:06 +01'00'.

On the other hand if I OnCRLNeeded event attach obtained CRL (does not matter if I take it with .NET HTTPClient, or simply download it by hand, from IE), signature is valid and revocation check is embedded into it.
I don't understand why SBB then can't put that CRL into signature in "normal" operation flow?

Quote
or you must provide an LDAP retriever

I could provide it (it works by me), but will it work at customer side, where they have proxy?
I must tell that I am very thankful to you as your support is precious, because my client will ask me (by sure) what's going on under the hood.
#35748
Posted: 01/28/2016 08:59:40
by Eugene Mayevski (EldoS Corp.)

The main problem you are having is that neither our component nor .NET HttpWebRequest can retrieve the CRL from the HTTP location. Is this correct?


Sincerely yours
Eugene Mayevski
#35749
Posted: 01/28/2016 09:37:43
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

Fact 1:
CRL can be retrieved from HTTP location, by hand (using browser)
Fact 2:
TElHTTPCRLRetriever can not retrieve CRL from HTTP location because it needs UserName and Password for proxy authentication which I can't provide.
Fact 3:
System.Net.Http.HttpClient (NET 4.5) can retrieve CRL from HTTP location without setting UserName and Password, even without setting Proxy address. It just somehow takes it from system settings and passes on logged users credentials.
#35750
Posted: 01/28/2016 09:46:09
by Eugene Mayevski (EldoS Corp.)

Then why aren't you using the custom retriever class that I mentioned in the previous messages? It should be able to retrieve the CRL then.


Sincerely yours
Eugene Mayevski
#35751
Posted: 01/28/2016 10:12:21
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

I am using it and it done it's job.
The problem is that even I set that, I have to set either MandatoryRevocationCheck on certificate validator to false, or IgnoreChainValidationErrors on handler to true. If this is the only way how to go through what is less evil? IgnoreChainValidationErrors or MandatoryRevocationCheck? If I use one of the, is my signature less valid? How could somebody on verification time using third party tool could even notice this? I want to underline that looking at Adobe reader's validator I don't see any problem.
#35753
Posted: 01/28/2016 15:13:25
by Ken Ivanov (EldoS Corp.)

It depends on the outcome you wish to achieve, there is no silver bullet here that would fit all environments.

What you have now is failing chain validation due to unavailability of a revocation information source. Depending on the particular certificate being checked, other revocation sources may be available - or they may be not. Depending on how this failure is treated by you and the validating party, the absence of the element may or may not be a problem (they might wish/be able to go for the missing revocation element by themselves and validate the signature anyway despite the element being missing from the signature).

By setting IgnoreChainValidationErrors you agree to ignore any kind of chain validation issues and try to validate the whole chain anyway. This approach is often used when a signature is created in a different environment to that where it is going to be validated with different trust circumstances (so the signer is able to create a valid signature despite not trusting the chain). This is a wider condition than switching MandatoryRevocationCheck off, as it also covers other validation issues. In this sense, using MandatoryRevocationCheck is, if I may say so, 'relatively more secure'. If we assume that no other validation issues are present, the effect of both methods is pretty much the same.

Ken
#35759
Posted: 01/29/2016 04:59:36
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

So even if Adobe says that signing certificate is to be trusted, because it does not appear in the CRL which is embedded in the signature, it still might mean that not everything is present?
#35783
Posted: 02/01/2016 03:40:04
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

Hi
Finaly I've got everything working on customer side! I have set Custom HTTP CRL retriever as Eugene proposed and left standard LDAP retriever. I have set MandatoryRevocationCheck to true and IgnoreChainValidationErrors to false and signing process still works well! This I could not test until I have come to customer side. Default LDAP retriever is working despite of proxy settings. Thank you for all your support it has been precious :)
#35785
Posted: 02/01/2016 04:13:29
by Ken Ivanov (EldoS Corp.)

Fantastic, we are glad that you've managed to sort the issue out. Thank you very much for keeping us updated.

Ken
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.

Reply

Statistics

Topic viewed 8429 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!