Angus Robertson

https://www.theregister.com/2025/04/14/ssl_tls_certificates/ https://www.feistyduck.com/newsletter/issue_124_certificate_lifetimes_to_shrink_to_just_forty_seven_days and numerous other sites that reported the same April vote, although https://cabforum.org/ has not yet been updated with the minutes of the meeting, or at least I can not find them. If you are interested in SSL/TLS, subscribe to the Feisty Duck monthly newsletter, it collects all the news. Angus

Currently, SSL/TLS certificates may be issued for a maximum period of 398 days, before renewal is required. The CA/Browser Forum recently voted to reduce this life span period in steps over the next four years. From 15th March 2026, life span is reduced to 200 days. From 15th March 2027, life span is reduced to 100 days. From 15th March 2029, life span is reduced to 47 days, but only 10 days for domain control validated certificates, such as most free certificates. These reduced life times reduce the effort needed to block compromised certificates, but also make manually updating server certificates more onerous. The Automatic Certificate Management Environment (ACME) developed by Let's Encrypt and used by many web servers, is now supported by other certificate vendors to issue free and commercial certificates automatically, and will hopefully be fully integrated with all major web servers by 2029. Let's Encrypt is adding a certificate profile to the ordering process, allowing alternate certificate types to be ordered, including six day life certificates later this year. It has also added a ACME command to get recommended renewal information, which is currently 30 days before a 90 day certificate expires. Applications are recommended to check renewal information regularly, currently every six hours, to check if certificates have been revoked. This will be important this summer when Let's Encrypt closes down the Online Certificate Status Protocol currently used to check if certificates are validly issued. A new version of the ICS TSslX509Certs component is currently being tested with these new ACME features, it will also attempt to support ordering certificates from Bypass, ZeroSSL, Google, DigiCert and ssl.com, although these most of these need accounts to be opened at the issuer before the ACME protocol can be used, so testing will not be quick and not all may be available initially. The main difference from Let's Encrypt is external accounting fields to link to the supplier's account, instead of just a public key. Minor changes to IcsHosts are needed for the ICS web server to handle certificate profiles and alternate suppliers, and to regularly update renewal information. These changes are already done in the OverbyteIcsX509CertsTst sample that is used to create ACME accounts and place certificate orders, that can be validated by an internal web server, external web servers such as Windows IIS and Windows Apache, and by Windows DNS server for wild card certificates. The sample supports multiple accounts for different suppliers, listing the status of all orders for those suppliers, and allowing ordering and renewals with a few clicks. I'll update this topic when the ICS web server is updated, hopefully within a week or two, meanwhile could anyone that has looked at alternate ACME suppliers let me know, to help with testing. Angus

For TCP and UDP client, setting LocalAddr attempts to bind to that address, if it exists. But it's generally a bad idea for clients to set LocalAddr, since IP addresses can be dynamic and change, interfaces can also come and go while your application is running. ICS has a component IcsIpChanges that reports such changes so servers in particular can know the IP address they are using has disappeared. BTW, please do not repeat everything I write, this is a threaded forum, so long quotes simply wastes space. Angus

In what way was my response unclear? Angus

For UDP server, TWSocket Addr and Port are set for listening. For UDP client, TWSocket LocalAddr and LocalPort may be set but are usually left blank, the remote address and port are specified in the SendTo method when sending data. Angus

After doing a couple of tests, it seems the SO_BSP_STATE API returns the local address allocated to the socket, usually 0.0.0.0, rather than the address chosen by Windows. We do get the random local port, so that could be used with the IpHlpConnsTable function to get a list of all connections on the PC, and search for the remote IP and local port, to find the local IP, major overhead to get a few bytes. Angus

I'm sure you are correct, but a few spare bytes in a buffer might provide future proofing. I'm surprised Socket_Address has not been used for other APIs, Microsoft has so many of these similar but not quite the same structures. Fortunately, ICS has a simple function to convert PSockAddrIn6 into a string. Angus

I've just got this working with new types Socket_Address = record { V9.5 used to store an IPv4 or IPv6 address } Sockaddr: PSockAddrIn6; SockaddrLength: Integer; end; TSocketAddress = Socket_Address; CSADDR_INFO = record { V9.5 used to connection IP information } LocalAddr: TSocketAddress; { family, address and port } RemoteAddr: TSocketAddress; iSocketType: Integer; { SOCK_STREAM or SOCK_DGRAM } iProtocol: Integer; { IPPROTO_TCP or IPPROTO_UDP } Buffer: array[0..64] of Byte; { space for PSockAddrIn6 records } end; TCSAddrInfo = CSADDR_INFO; Need to ensure it handles all ways of connecting, and update a sample to show the result, hopefully later today. Angus

Sorry, no time to debug this at the moment. Angus

You should wait until the socket is connected before trying to get socket connected information, use the OnSessionConnected event. Angus

Generally, you set the LocalAddr, LocalAddr6 and SocketFamily to specify which of multiple IP addresses is to be used. Currently, TWSocket does not have any properties to show which IP address Windows choose for an outbound connection only for incoming listen connections. Windows Vista added a getsockopt of SO_BSP_STATE that should return the local and remote addresses and ports for a connection, but it is not used by ICS, you try it with the TSocket handle. I'll put it on my long term wish list, but we seem to have managed for a long time without knowing the real local address. Angus

Set the component ResponseNoException property to true, and the exceptions are replaced by messages. This is a historical thing to not break old applications, but should probably default to true now. Angus

OpenSSL has released a new feature version 3.5.0 (no security fixes). It includes support for new Post Quantum Cryptography (PQC) algorithms (ML-KEM, ML-DSA and SLH-DSA) and for server side QUIC (RFC 9000). ICS has no plans for QUIC support, not yet investigated PQC, don't believe any low level changes are needed, maybe changes to the cipher lists. There are other TLS/SSL changes due for IVS V9.5, so will investigate shortly. This is a long term support release with fixes and security updates for five years, until April 2030. Windows binaries are available in SVN and the overnight zip file and separately from https://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp In addition to the three DLL files, the zips include compiled RES resource files that contain the same DLLs, text files and version information, see the RC file. The RES file may be linked into application EXE files and code then used to extract the DLLs from the resource to a temporary directory to avoid distributing them separately. ICS V9.1 and later optionally support loading the resource file. These OpenSSL versions are included with ICS V9.5 beta available from SVN and the overnight zip. ICS V9.5 beta now defaults to using OpenSSL 3.5.0, provided the new OverbyteIcsDefs.inc files is installed, or you undefine OpenSSL_35 and suppress an earlier version. . Angus

V8.70 was three years ago, so the included in the samples directory will be aging, some will have expired and new ones added since. With that release you had to specify the root bundle to load, while with V9.1 and later the root bundle is loaded automatically when an SSL application starts, so you can mostly ignore them. If you are stuck on an old version, you can download the latest root bundles from https://www.magsys.co.uk/delphi/magics.asp Angus

There is an ICS component TMsCertTools that can be used to create self signed cerrtificates, or create certificates signed by a CA root certificate, or read any certificate, and it has methods LoadOneFromStore and SaveToStorePfx that read and write to the Windows Certificate Store, optionally with private keys and intermediates. Look at PemTools sample which uses it extensively. So you can create your own CreateSelfSignCertEx using TMsCertTools instead of TSslCertTools that will install into the Windows Certificate Store. By certificate fingerprint, you probably mean the Sha1Hex or Sha256Hex of the DER X509 content, and those are methods for TX509Baae/etc. However, ICS does not currently have any means to access IIS Site Bindings to associate certificates with IP addresses and ports. I believe there are COM object methods that handle that, but not Windows APIs. I do it manually every two months for my new Let's Encrypt certificates. For your client certificates, you should create your own CA root certificate using PemTool (tick Root Certificate Authority), similar to the ICS CA root, and maybe intermediate CA as well (as ICS does) since Windows does not always like end user certificates directly signed by a root, then CreateSelfSignCertEx will create your client certificates. Beware browsers nowadays don't usually use the Windows Store, and will sometimes also complain about manually added CA certificates, since these are commonly used by AV companies (and hackers) to intercept SSL communications, Edge currently complains about the ICS root CA, unless I've missed something. Angus