Leaderboard

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

I'm apparently not getting the message through; There is nothing special required, by neither the source nor the destination, in order to support copy/paste of files via RDP. The RDP support is transparent. If your remote application copies data onto the clipboard in the FileContents & FileGroupDescriptor formats, then the local destination will be able to paste it. Waitamoment.. I just realized that you just used remote desktop as an example. You will not actually be using remote desktop. Is that correct? So you are actually just asking how remote desktop makes the remote clipboard available to the client and how to replicate that functionality in your own client/server system. Well, I don't know the exact details of how it's done but I know enough about the clipboard and dragdrop that I can guess. On the server, the RDP host monitors the clipboard (there's an API for that). When data is copied onto the clipboard, in one of the formats supported by RDP, the server sends a message to the client with the meta data (data formats, size, etc.) of the clipboard data. On the client, the RDP client receives the message and copies the (meta) data onto the local clipboard using an IDataObject interface. On the client, some application pastes from the clipboard... The local clipboard asks the local data source, via the IDataObject interface, for the data. The local RDP receives the data request on its IDataObject interface and forwards this request to the remote RDP server. The remote RDP server in turn does the same: It asks the remote clipboard for the data, the remote clipboard asks the remote data source (whoever copied the data onto the clipboard in the first place), etc. Once the remote RDP server has the data it sends it back to the local RDP client which then supplies it, through the IDataObject, to the local application. Done. Paste complete. A normal paste can cause data to be sent back, through IDataObject, notifying the source about the paste. I don't know if RDP propagates this information all the way back to the server.

If you are a seasoned Delphi developer you know that new features are not usable for like half a decade or so...