Jump to content

Angus Robertson

Members
  • Content Count

    2136
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by Angus Robertson

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. Yes, please email your bad certificate file, my address is in readme8.txt. Angus
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. Angus Robertson

    TSslSmtpCli in Console App

    Perhaps FastCGI instead, which runs continually. I'm just updating the Jose stuff to handle the server side of Json Web Signing/Tokens for REST servers, currently it only does JWS/JWT for REST clients, and was thinking about how it could be used with web servers other than ICS, FastCGI seems a possibility. TIcsMailQueue can be used separately to queue and send email, the queue format is standard SMTP pick-up as used by Microsoft, although I've not used it like that. Angus
  25. Angus Robertson

    TSslSmtpCli in Console App

    You could also try using TIcsMailQueue which sends mail in the same way as TSslSmtpCli but runs a mail queue with repeated retries to multiple servers on failure. Your application would need to keep running until the queue was empty, and not run multiple copies, but mail is more likely to be delivered. Angus
×