Migrating from Writable to Read-Only (Digitally Signed) License Files
Read-only (digitally signed) license files are more secure than writable ones. This guide covers what to expect when you move existing customers to read-only and how to harden the result. For the difference between the two, see Choosing Between Read-only and Writable License Files.
Why read-only is more secure
Read-only license files are digitally signed. Your encryption key data (the "envelope") bundles two keys: the Server Key and the Client Key. Writable (self-signed) licenses are protected with the Client Key, which works like a symmetric ("secret-key") algorithm — the same key data is present in both SOLO Server and your application, so anyone who recovered your envelope could create writable licenses. Read-only licenses are different: they are signed by SOLO Server using the private portion of the Server Key, which only SOLO Server holds. Your application has only the Server Key's public data, which is enough to verify a read-only license but not to create one. So even if someone recovered your envelope, they could only forge writable licenses — which an application configured to require read-only will reject.
Existing installs will prompt for re-activation (this is expected)
Read-only and writable are different file formats, and the license class in your licensing implementation determines which type your application accepts. When you ship a build that implements only read-only licenses, any previously stored writable license file is no longer valid, so the application correctly prompts for a fresh activation. Requiring that one-time re-activation is the cleanest and most secure way to move existing customers onto read-only.
Steps
- Update your licensing implementation to use the read-only license class (PLUSManaged).
- Ship the new build. Existing writable-license users re-activate once (expected).
- Add the hardening below.
Hardening read-only licenses
Because your application cannot update the LastUpdated timestamp inside a read-only file, add a few checks to guard against a back-dated system clock: - Store a separate local "last used" date and compare it against the current system clock. - Compare the system clock against the license SignatureDate (the file's creation date). - Run periodic Refresh validations with SOLO Server, which checks the system clock within a 24-hour window across time zones. - Optionally, treat an EffectiveEndDate more than about a year past SignatureDate as suspicious (not strictly necessary with signed read-only files).