Jump to content

Angus Robertson

Members
  • Content Count

    1812
  • Joined

  • Last visited

  • Days Won

    33

Everything posted by Angus Robertson

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. Yes, please email your bad certificate file, my address is in readme8.txt. Angus
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. The trusted root certificate currently used by Let's Encrypt, DST Root CA X3, expires in September 2021. Let's Encrypt issued it's own root certificate, ISRG Root X1, some time ago and it is now available in all major browsers. ICS added it to our bundles three years ago in June 2017 with V8.49. From 8th July 2020, Let's Encrypt will start issuing new certificates signed by an intermediate using the new ISRG root certificate, and the chain will only successfully validate for ICS applications that have the new root. If the internal ICS root bundle is used it must be a new release, but a newer external PEM bundle file can be distributed for use with older ICS applications so they can still access web sites with Let's Encrypt certificates. Because Let's Encrypt certificates expire in three months, they will all be using the new root by mid October 2020. Angus
  24. The safest way to read bundle files with unicode characters will be to strip out all the comments I add before passing them to OpenSSL. For maintenance, adding certificate fields makes life easy, I hate long blocks of base64, and previously OpenSSL has seemed good at ignoring added text. But if the comments are causing trouble, they should go. Angus
  25. Thanks, I've fixed certs 10 and 12, that was me on auto pilot copying selected certificates from the automatically generated bundle files and manually converting them into constants with global replace, really need to automate that to avoid errors. But since all the certificates are concatenated in order, it should not make any difference. in theory. Not sure how those • 8-bit characters got into the literals, but I've removed them, and from TrustedCABundle, the larger bundles are built in a different way. Very strange that errors don't show up consistently. I have seen a problem with PSTACK on servers, where stacks were being continually rebuilt to validate certificates,, but that went away when I simplified the code to avoid rebuilding so often. These fixes should be in SVN tomorrow, when I've finished some other stuff. Angus
×