The Flexera Community is currently in maintenance mode to prepare for the upcoming launch of the new community. Click here for more information.
Hello,
We're running a on-prem FNMS 2023 R2. The certificate FlexeraCodeSigning used to sign the assembly SqlProceduresClr.dll used in SQL Server will expire on September 4th. Is the solution will still be working after this date with the standard db settings ( TRUSTWORTHY = off, clr enabled = 1 and clr strict security = 1)? I know that a new certificate has been released, but it won't match our current dll's one.
Thanks for your help.
Jérémie
‎Aug 29, 2024 03:33 AM
This certificate needed to be current (not expired) at the point in time when it was used to sign DLLs, which it was. The certificate does not need to be renewed to continue to use DLLs (including the SqlProceduresClr.dll file) that were signed using the certificate in the past.
DLLs in future releases of FlexNet Manager Suite will need to be signed by a new certificate, as the older certificates in use will all (shortly) have expired.
‎Aug 29, 2024 04:33 AM
This certificate needed to be current (not expired) at the point in time when it was used to sign DLLs, which it was. The certificate does not need to be renewed to continue to use DLLs (including the SqlProceduresClr.dll file) that were signed using the certificate in the past.
DLLs in future releases of FlexNet Manager Suite will need to be signed by a new certificate, as the older certificates in use will all (shortly) have expired.
‎Aug 29, 2024 04:33 AM
Thanks Chris,
I was concerned because when we migrated from 2020 R1 to 2023 R2, DB migration failed during assembly import because of certificate mismatch between the one installed in the master db and the one used to sign the different assembly versions. We had to disable "clr strict security" to get it work...
But now, since the assembly is already installed, based on what you said, we don't need to import the latest certificate.
Have a nice day.
Jérémie
‎Aug 29, 2024 05:06 AM
Disabling "clr strict security" is not a solution. At least it will not be one in managed SQL Server environments.
Depending on how many versions of FNMS you're migrating over, you may have to switch the certificate on your SQL Server between major versions. I usually start the migration with the existing certificate until it hits the "certificate ceiling", then switch to the new certificate and continue.
‎Aug 30, 2024 01:59 AM