Jump to content

Odd (OpenSSL?) bug and types in X509 certs

Recommended Posts

2 minutes ago, m227 said:

It is one of a standards of signing files (an fie extension as well). Based on XML.

You are just parsing the XML and extracting the certificate, right ?

Share this post

Link to post

Well, work is more complicated. I parse and visualize special kind of financial XML files (in a semi tree structure), sometimes they are signed with XAdES, sometimes XAdES file has my XML in it, sometimes it is as additional node to my XML Files.

But when my XML files are in XAdES or XAdES is part of them, I am to read XAdES signatures to show their signers. I extract also attachments and decode them, I also validate XML files using Xerces (DI XML).

1359984978_2020-06-2522_14_30-BAUDZIEDZIC.xml-U-FinStudiov1_04.1.thumb.png.1c39f2884755857bfe3d3646bf0bdf0f.pngScreen attached. Some XML files (with millions of rows) I render to SQLite database with some tables (when Excel is too short to visualize them).

  • Like 1

Share this post

Link to post

Looks nice and professional, congratulations.


That was the point of my last question, extracting certificate or the signature without validation is worthless, but you already knew were i am going.



Though i would suggest to use your own application to do the signing and the verification, to my knowledge only few components/libraries can do XAdES with Delphi, 

https://www.tmssoftware.com/site/tmscrypto.asp may the suitable for price and pure pascal code

https://www.chilkatsoft.com/ may be good for price with huge library, very huge may be the authors themselves didn't count them, ActiveX though.

SecureBlackBox this one is not cheap and not sure if the source is will available, mine expired few years back but i am still happy with it.

Share this post

Link to post

Thanx, I'm not a low level component writer neither I aspire to. For now we have no need to sign/verify signatures so it is not in my scope of view.

Share this post

Link to post

I'd need to do more reading on XAdES to see what real cryptography is involved, but I've just finished updating the ICS Jose unit to handle signing and verification using JWK, JWS and JWT which involves hash digests, private and public RSA/EC keys and is used for REST APIs like Let's Encrypt, Google and Microsoft.  Anything using XML will be an older generation and should be easy to support in ICS, if there is a demand. 




Share this post

Link to post

I don't urge to implement XAdES in ICS, as I already handle small part of it which I need (with help of ICS/OpenSSL).

However handling XAdES-es by some popular library like ICS would be nice feature.

To parse XMLs I use OXML for many years with success.

My current not too consistent code looks like:


function GetSignaturesBase64FromXAdES(const AFileName: String; AFormat: X509CertificateFormat = X509CF_BASE64): TStringDynArray;

  function AddHeader(AString: String): String;
    Result := '-----BEGIN CERTIFICATE-----' + sLineBreak + AString + sLineBreak +
              '-----END CERTIFICATE-----';

  FXML      : IXMLDocument;
  ANodeList : IXMLNodeList;
  i         : Integer;
  Base64    : String;
  SetLength(Result, 0);
  FXML := CreateXMLDoc;
    FXML.ReaderSettings.StrictXML := False;
    FXML.DocumentElement.SelectNodesNS('http://www.w3.org/2000/09/xmldsig#', '//Signature/KeyInfo/X509Data/X509Certificate' , ANodeList);

    for i  := 0 to ANodeList.Count - 1 do
      Base64 := Trim(ANodeList[i].ChildNodes[0].NodeValue);  // 2020-03-30 del CRLF at start and end

      case AFormat of
      X509CF_BASE64:             Result := Result + [Base64];
      X509CF_BASE64_WITH_HEADER: Result := Result + [AddHeader(Base64)];
      X509CF_BINARY:             Result := Result + [DecodeBase64(Base64)];
      // StringToFile(Format('Cert%d.txt', [i]), Result[i]);
    FXML := nil;


Share this post

Link to post
23 minutes ago, Angus Robertson said:

I'd need to do more reading on XAdES to see what real cryptography is involved,

The fact that XAdES is more involved with XML than cryptography make implementing it big deal and huge work, and then comes the distinguished profile along with individuals and different countries standards.



https://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf    <-- EU standard


10 hours ago, m227 said:

I'm not a low level component writer neither I aspire to.

I was pointing to minimize the dependency on 3rd-party (Xerces), because i think you are using it only for the sign/verify operation, less 3rd-party means less hustle with open source licenses, even OpenSSL need one.


Looking at TMS Cryptography Pack documentation, it doesn't mention timestamp anywhere, so not sure if it does validate/verify it or not or even support it or not, same goes to Chilkat, looking at SBB editions and prices, Lite edition doesn't have XAdES, while full version might not be with source with that price.


Dear @m227 , stick to Xerces !


Share this post

Link to post

I found Xerces to be industry standard for XML validaion against XSD-s (Oxygen XML Editor and probably Altova XMLSpy use it). Along with generous Apache license it is the only choice. I use it by DI XML (paid) wrapper. It covers most XML tasks, however to fiddle with XML I use Ondrejs Pokorny OXML which by nature is lightning fast (pure Delphi).

Share this post

Link to post

Agnus, I have two suggestions for ICS to consider by ICS comunity, as i see it the most OpenSSL compliant complete suit for Delphi.


1) The ability to build the exe with OpenSSL as static lib or just DLL as resource loaded at runtime, using https://github.com/DSPlayer/memorymodule , been using it for years now without problem, but not with OpenSSL (libcrypto, libssl) , may be it is challenging but i think it is doable, and i fully understand the impact on doing so, as OpenSSL might need a critical security update, and in that case you need to rebuild exe itself, on other hand OpenSSL very often breaks compatibility between versions and you need the exe to be updated, at least by having internal library, you eliminate the risk factor of replacing those external DLL's with malicious ones, which does happen more than you can think everywhere in the world, code signing there will not protect anyone, as DLL's are way less monitored (if any) than application exe's.


2) ICS Authenticode, to sign Windows binaries, in other words a replacement for SignTool, this is doable, and i don't think full feature set like SignTool is needed, just add signature or two and remove current signatures and of course with timestamping, it might be fun to implement too, OpenSSL handle PKCS7 perfectly, and also has support for RFC 3161 out of the box, and Microsoft standard for PE Authenticode is very simple, 


https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#appendix-a-calculating-authenticode-pe-image-hash  docx version
https://www.symbolcrash.com/wp-content/uploads/2019/02/Authenticode_PE-1.pdf for better pdf visual version
To handle/process PKCS7, with Windows CryptoAPI , and also has timestamping API's , they are helpful in comparing results.



extra info about TimeStamp and rfc3161 with OpenSSL




Why is this SignTool needed?

To build remote signing, where the certificate ( or just the private key) are stored on remote server and need to be accessed by counter part that can be used remotely, example of an application i already build for few clients, the team boss trust his team completely but he want to stay on safe side and keep logging who is doing what when it comes to sign an EXE with the company certificate, the EXE's are being built with unity and they are very huge, so sending it over and back to be signed is time consuming, with his requested application the been signed on client side with sending nothing more than very short signatures data itself, while using this signing tool required credential from the user (team member) that sent and archived on the server side, with few other things like time and size and file name ..etc , just to make sure of the responsibility of using OV certificate are honored, the OV certificate with its private key are on a pc in his home.

Share this post

Link to post

If you have already parsed the XML, and can compose the exact signed content, the ICS function IcsAsymVerifyDigest will verify with a private key and the hash digest, there are other function to create the digest with a private key and for HMAC signing with a shared secret. 


ICS will only work with specific OpenSSL versions it understands, and currently supports three major version, soon to be four when OpenSSL 3.0 enters beta next month.


You could probably embed the DLLs as a resource, unpack to tempdir and open them there, but I'm not planning anything like that.


There is an open source code signing project using OpenSSL https://github.com/mtrojnar/osslsigncode but it's 5,000 lines of C code and not trivial, Microsoft has made code signing quite complicated.  If anyone has built a Windows binary, I'd love to play with it.




Share this post

Link to post
11 minutes ago, Angus Robertson said:

If anyone has built a Windows binary, I'd love to play with it.

I didn't understand what you are referring to, osslsigncode or any Windows binary ( with/out OpenSSL)?

Share this post

Link to post

The osslsigncode project is an alternative to signtool, I'd like to play with it, but I'm not a C developer.


Currently I have to enter a password for every single EXE or DLL I sign with the ICS open source certificate because the key is only a secure dongle, it's a pain. 



Share this post

Link to post

I feel you, the thing is many case the driver of that dongle is asking and nothing can be done about it, but to be sure try to download the trial of SecureBlackBox and see for yourself, if you can in code input the login credentials or not.

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now