Angus Robertson

PosEx was available in Delphi 2007, but became obsolete in XE3 when Pos got a third offset argument. 

function Pos(const SubStr, Str: UnicodeString; Offset: Integer = 1): Integer;

Abgus

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. 

Angus

To save me looking at lots of old compilers, does anyone know in which version of Delphi that Pos got an extra argument to become equivalent to PosEx in D2007?  Hopefully D2009?

Angus

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.

Angus

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. 

Angus

Never heard of XAdES, but if it's a toolkit they should not be generating unwrapped base64 lines, I'd raise that as a bug with them on the basis that OpenSSL does not correctly support it...

Angus

Yes, I've only tried two of your four certificates, but they can be read by OpenSSL with short lines.  If none had worked with long lines, this would have been a lot easier to diagnose.

Angus

I made a mistake word wrapping one of the bad certificates and lost a character, when corrected it reads correctly with ICS and OpenSSL.

It is frustrating OpenSSL does not handle unwrapped certificates consistently and I've raised that as an issue.

But Michal can fix his original problem by ensuring the files are created according to the RFC with 64 character long lines, they are from some source other than ICS.   In theory I could word wrap them, but I think I'll just add a better error if OpenSSL fails. 

Angus

The original certificates are unwrapped base64 and that is how I tested them. however I manually line wrapped them for the OpenSSL mailing list since email does like 2,500 long lines. 

When I rest them line wrapped, my latest ICS says 'Reading X509 Base64 certificate: Error Cert 1 - error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode' for the bad certificate and the asn1parase command works for the OK certificate and gives a real error for the bad one.

I'll fix ICS to reject unwrapped certificates since OpenSSL can not reliably handle them. 

Angus

Another OpenSSL user has briefly tested the certificates and believes they contain badly formed UTF8, probably ANSI which is how this topic started.  The issue will be whether OpenSSL should open badly formatted certificates in future, even if it did in the past. 

Angus

No, don't need any more from you, OpenSSL should be able to read these certificates or say what is wrong with them, so it's their bug, not ours.

Angus

The certificates do not have private keys, but do have private names, they are client certificates.  No purpose in posting them here, but I will escalate to OpenSSL.  

Angus

My point was the OpenSSL error is so serious it is not even reported, which is why I want to escalate it to OpenSSL support, let them examine your certificates and hopefully fix it?

Angus

Is it okay to put your SSL certificates in the OpenSSL mailing list, to try and find out why some can not be read? 

I've improved the reading of certificate files and bundles to get some meaningful errors, rather than stack error.  For instance if I remove some lines of base64, I get  'Error Cert 4 - error:0D07209B:asn1 encoding routines:ASN1_get_object:too long' and more ASN1 errors, but reading your bad certificates just says 'Error Cert 1 - error:00000000:lib(0):func(0):reason(0)' which essentially means no error found. 

Angus

They are both ICS sites, the wiki site is linked from the main site as 'Find very latest update here' and is updated more often.  As you have been told twice, the latest version is V8.64 from May 2020, not the 18 month old version on the main site.

Angus

The best place to download ICS and OpenSSL is http://wiki.overbyte.eu/wiki/index.php/ICS_Download and the latest is V8.64.  However the zero seconds fix was 15 years ago. 

Angus

Not sure from this thread what you are doing with these certificates, but if they are on a public web server you can try a test at https://www.ssllabs.com/ssltest/ which is good at testing certificate chains for errors.

Angus

Probably the certificate files are incorrectly formatted but previously the error was ignored, and this is corrected. 

There is a web site that parses ASN1 https://lapo.it/asn1js/ and it reads all the files OK, but that does not mean they are valid X509 certificates. 

ICS is not the only server using OpenSSL 1.1.1, Certum should make their certificates are compatible with the latest and greatest or others will complain as well. 

Angus

Thanks for the files.  ICS will read two of them OK, but not the other two. 

Nor can the openssl.exe tool read the bad files using the x509 command. 

The asn1parse command is unable to read any of your files, but is fine with all mine.  So there is something strange about the construction of these Certum certificates. 

Angus

Yes, please email your bad certificate file, my address is in readme8.txt. 

Angus

Okay, so something changed in 1,1,1 reading certificates.

Unfortunately we are using an old undocumented API PEM_X509_INFO_read_bio which has worked for 15 years, must see if there is something better.

Angus

OpenSSL 1.1.0 is also old and no longer supported, you should be using 1.1.1g from http://wiki.overbyte.eu/wiki/index.php/ICS_Download which is the latest, but is unlikely to make much difference to certificate errors. 

I am currently making certificate reading more robust, but the offending certificates in the bundles have been there a long time so there is no clear reason why we are now seeing errors on just a few PCs. 

Angus

The problem being discussed here is PEM certificate files with extra content outside the base64 blocks, where there may be text outside the 7-bit ASCII range, and something gets confused deciding whether this is UTF8 or ANSI, not quite sure what yet,  or why the new Windows 10 force UTF8 APIs setting would have any effect on content embedded in a De[phi application and not being read from a file. 

So unless your XAdES file has extra stuff you did not post, it's not this issue.

ICS currently supports three versions of OpenSSL with two different DLL names,  If you set the global GSSLEAY_DLL_IgnoreNew to true before calling any SSL functions, it will load the old unsupported libeay32.dll instead of the modern one, and it's possible they do not understand UTF8 so work for you.  But Indy still uses the older DLLs, so confused as to why removing the new ones will upset it.  

There is another global variable GSSL_DLL_DIR you can set to the directory from which to load OpenSSL DLLs, again set before calling anything, needs trailing backslash.

Angus

Our root stores were taken from the Windows store on one of my servers until last year, but Windows now only includes certificates needed by the server, and downloads new ones it needs. 

http://wiki.overbyte.eu/wiki/index.php/FAQ_SSL/TLS_Certificate_Authority_Root_Stores explains how we build them now.  But all the textual comments are mine, to keep track of them.

Angus

There is a fix for the internal root certificate bundle in SVN, I simply suppressed literal comments from the constants which saves space in binaries and avoids any 8-bit characters being read.   I added a button in the PemTool sample that loads and displays the various ICS bundles, to make sure they work. 

I need to look more closely at the various functions in ICS that save and read certificates to make sure they all support UTF8, and so that only real base64 PEM content is sent to OpenSSL to avoid any problems reading existing files, not just roots.  That will all need careful testing. 

Angus