ObtainLicenseService may retrieve outdated license version

Bug

Summary

ObtainLicenseService is used by the LicensesController when you try to download or copy-to-clipboard a license. If an existing and "current" license exists already, it returns that. Else, it generates a new license by building from subscription data

The service will try to locate an existing "current" license based on 3 license attributes: subscription name, user count, and expires at. However, sometimes a subscription has changed but none of those 3 attributes have, so ObtainLicenseService fetches an outdated license.

For example (internal only), adding Duo into a license changes the subscription_id (not the name) but may otherwise not update any other attribute. Thus, if an existing offline license key already exists, ObtainLicenseService retrieves that now-outdated license file rather than generate a new one with the addon product

Note that this likely does not have any impact on cloud licenses being retrieved or created via seatlinks, since that appears to follow its own pathway to invoking a separate service, Licensing::BuildLicenseFromSubscriptionService.

Steps to reproduce

this offline license existed already for version 1 of the subscription, created on 2025-01-14
later, a product swap occurred (duo pro for ent) resulting in version 2 of the subscription
impersonating the user and copying the key to clipboard continued to serve license ID 1312239

I manually created a new version of the key so this particular example is likely no longer repeatable.

What is the current bug behavior?

Outdated license key is returned to end user

What is the expected correct behavior?

Most recent version of the license should always be returned, with caveats:

It might be an intentional design to limit the attributes that force license regeneration. for example, contact name changes may not always be a desirable reason to recreate a new license.

Is there a reason to locate by name instead of ID, though? The ID only changes when subscription level data changes, and IDs are non-ambiguous.

Workarounds

Manually generate from admin side

Reported examples

Support Priority Score: (1, -, -, -, -, -, -, -, -, -, 2) => 3

Edited Sep 03, 2025 by Keven Hughes