EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Certificate Validation

Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.
#4359
Posted: 11/20/2007 13:01:29
by Dmytro Bogatskyy (EldoS Corp.)

Quote
yes, i send the signed xml as attachment

Thank you, I found a bug. A fix will be included in the next build.
#4370
Posted: 11/21/2007 12:30:20
by Nuno Guedes (Basic support level)
Joined: 08/13/2007
Posts: 87

no problem, it´s my role using your library.

Need to create a helpdesk ticket?

thanks for all the help
#4372
Posted: 11/21/2007 13:06:31
by Dmytro Bogatskyy (EldoS Corp.)

Quote
Need to create a helpdesk ticket?

Yes, please.
Or you can wait for next build. It is expected in two-three weeks.
#4375
Posted: 11/22/2007 06:40:54
by Nuno Guedes (Basic support level)
Joined: 08/13/2007
Posts: 87

yes, i can wait.

thanks for all
#4424
Posted: 12/03/2007 12:23:35
by Nuno Guedes (Basic support level)
Joined: 08/13/2007
Posts: 87

one more problem...

i created a CA on WINDOWS server 2003 and issued a certificate for one user.

I signed a file with this certificate.

For verifying the certificates used to create the signatures i do the following tasks:
- Load to a MemoryCertStorage all the certificates present is WinStorage
- Add to the MemoryCertStorage all the certificates presents in the KeyInfo element.
- Get the information from signingcertificate element (issuer, digest and serial)
- Find the SigningCertificate in the MemoryCertStorage
Code
            TElCertificateLookup lookup = new TElCertificateLookup();
            lookup.SerialNumber = Verifier.Signature.QualifyingProperties.SignedProperties.SignedSignatureProperties.SigningCertificate[0].IssuerSerial.SerialNumber;
            lookup.CertificateHashAlgorithm = SBConstants.Unit.SB_ALGORITHM_DGST_SHA1;
            lookup.CertificateHash = Verifier.Signature.QualifyingProperties.SignedProperties.SignedSignatureProperties.SigningCertificate[0].CertDigest.DigestValue;
            lookup.Criteria = SBCustomCertStorage.Unit.lcCertificateHash | SBCustomCertStorage.Unit.lcSerialNumber;
            lookup.Options = SBCustomCertStorage.Unit.loExactMatch | SBCustomCertStorage.Unit.loMatchAll;

            // Procurar o primeiro certificado que possua os requisitos anteriormente especificados
            int index = memCertStorage.FindFirst(lookup);


index return the value "-1".
Debugging i verified that Verifier.....SerialNumber is a byte[12] while certificate in memoryCertStorage is a byte[10].

Verifier: 0 0 97 16 10 175 0 0 0 0 0 2
memCertStorage: 97 16 10 175 0 0 0 0 0 2

why the verifier have a serialnumber with different lenght?

thanks
#4425
Posted: 12/03/2007 13:00:04
by Nuno Guedes (Basic support level)
Joined: 08/13/2007
Posts: 87

another one...

when i verify the

cert.Extensions.CRLDistributionPoints.get_DistributionPoints(0).Name.count returns 2

The first name have "ldap:///CN=CertificateAuthority,CN=TFCGesDocServer,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=tfcgesdoc,DC=edu?certificateRevocationList?base?objectClass=cRLDistributionPoint" as UniformResourceIdentifier.

The second name have "http://tfcgesdocserver.tfcgesdoc.edu/CertEnroll/CertificateAuthority.crl".

These are two types for access the CRL, the first by LDAP and the second by http.

the problem is that both of names have the propertie NameType as gnUniformResourceIdentifier.

The LDAP name should´t have the NameType as gnDirectoryName?

thanks
#4426
Posted: 12/03/2007 16:00:11
by Dmytro Bogatskyy (EldoS Corp.)

Quote
Verifier: 0 0 97 16 10 175 0 0 0 0 0 2
memCertStorage: 97 16 10 175 0 0 0 0 0 2

The serial number in xml stored as an integer, so the starting zeros not present in xml element.
It seems, that in your case, you should compare the serial number too.
Try this:
SBUtils.Unit.CompareMem(SerialNumber, SBXMLDefs.Unit.ToCryptoBinary(cert.SerialNumber))
#4427
Posted: 12/03/2007 16:12:07
by Dmytro Bogatskyy (EldoS Corp.)

Quote
The LDAP name should´t have the NameType as gnDirectoryName?

See: http://www.ietf.org/rfc/rfc4325.txt
Code
Where the information is available via LDAP, the accessLocation
SHOULD be a uniformResourceIdentifier.

#4434
Posted: 12/04/2007 09:48:25
by Nuno Guedes (Basic support level)
Joined: 08/13/2007
Posts: 87

Quote
SBUtils.Unit.CompareMem(S­erialNumber, SBXMLDefs.Unit.ToCryptoBi­nary(cert.SerialNumber))

it works, but is SBXMLSec.Unit.ToCryptoBinary.


Quote
Quote
The LDAP name should´t have the NameType as gnDirectoryName?

See: http://www.ietf.org/rfc/r­fc4325.txt
Code
Where the information is available via LDAP, the accessLocation
SHOULD be a uniformResourceIdentifier­.


thanks for the help


Now i cant understand how to load the CRL.

Code
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://xxxx");

HttpWebResponse webresponse;

webresponse = (HttpWebResponse)request.GetResponse();

Stream m = webresponse.GetResponseStream();

crl.LoadFromStream(m, 0);



it returns the following exception:

Code
System.Web.Services.Protocols.SoapException was unhandled by user code
  Message="System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.NotSupportedException: This stream does not support seek operations.\n   at System.Net.ConnectStream.get_Length()\n   at SBCRL.TElCertificateRevocationList.LoadFromStream(Stream Stream, Int32 Count)\n  
#4435
Posted: 12/04/2007 12:54:27
by Nuno Guedes (Basic support level)
Joined: 08/13/2007
Posts: 87

with the Windows 2003 CA i have new problems:

the certificate created have the following issuer RDN:
Code
CN = CertificateAuthority DC = eBankaSignatures


But on the xml signed file, on signingcertificate element, the RDN it´s only:
Code
CN = CertificateAuthority


my idea is to get the value from both CN and compare, as i understand i should use ...IssuerRDN.GetValuesByOID() rigth?

How can i know the OID for CN? i searched in some SB... librarys but dindnt find any constant with his value...

thanks
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

Topic viewed 28452 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!