Skip to main content
minor edits for consistency / accuracy
Source Link
Solomon Rutzky
  • 69.5k
  • 8
  • 155
  • 300
  1. Create a Certificate in the Database where the Assembly resides
  2. Back up the Certificate (both Public and Private Keys) to files (optional)
  3. Sign the Assembly (or Assemblies) with the Certificate
  4. Remove the Private Key (it can be restored later from the backup file) (optional)
  5. For each additional Database that has unsigned, SAFE Assemblies:
  6. Either skip this sub-step (i.e. skip to Step 6), complete the steps, and repeat the whole process (this will result in one Certificate per each Database needing one), OR
  7. Do the following (this will result in one Certificate total, which will be used for all Databases):
    1. Create the same Certificate from the backup files (including the Private Key!)
    2. Sign the Assembly (or Assemblies) with the Certificate
    3. Remove the Private Key (it can be restored later from the backup file)
  8. Copy Certificate to [master] (Public Key only!)
  9. Create Login from Certificate
  10. Grant the Certificate-based Login the UNSAFE ASSEMBLY permission

A simple example of this (minus the optional backup and Private Key removal) would be:

  1. Create a Certificate in the Database where the Assembly resides
  2. Back up the Certificate (both Public and Private Keys) to files
  3. Sign the Assembly (or Assemblies) with the Certificate
  4. Remove the Private Key (it can be restored later from the backup file)
  5. For each additional Database that has unsigned, SAFE Assemblies:
  6. Either skip this sub-step (i.e. skip to Step 6), complete the steps, and repeat the whole process (this will result in one Certificate per each Database needing one), OR
  7. Do the following (this will result in one Certificate total, which will be used for all Databases):
    1. Create the same Certificate from the backup files (including the Private Key!)
    2. Sign the Assembly (or Assemblies) with the Certificate
    3. Remove the Private Key (it can be restored later from the backup file)
  8. Copy Certificate to [master] (Public Key only!)
  9. Create Login from Certificate

A simple example of this would be:

  1. Create a Certificate in the Database where the Assembly resides
  2. Back up the Certificate (both Public and Private Keys) to files (optional)
  3. Sign the Assembly (or Assemblies) with the Certificate
  4. Remove the Private Key (it can be restored later from the backup file) (optional)
  5. For each additional Database that has unsigned, SAFE Assemblies:
  6. Either skip this sub-step (i.e. skip to Step 6), complete the steps, and repeat the whole process (this will result in one Certificate per each Database needing one), OR
  7. Do the following (this will result in one Certificate total, which will be used for all Databases):
    1. Create the same Certificate from the backup files (including the Private Key!)
    2. Sign the Assembly (or Assemblies) with the Certificate
    3. Remove the Private Key (it can be restored later from the backup file)
  8. Copy Certificate to [master] (Public Key only!)
  9. Create Login from Certificate
  10. Grant the Certificate-based Login the UNSAFE ASSEMBLY permission

A simple example of this (minus the optional backup and Private Key removal) would be:

added clarification
Source Link
Solomon Rutzky
  • 69.5k
  • 8
  • 155
  • 300
  • the Database property of TRUSTWORTHY is ON (don't do this as it is an unnecessary security risk) and the Login that is the database owner (i.e. same SID used by the [dbo] User) needs to have the UNSAFE ASSEMBLY permission (which it might already have if the owner is sa or a member of the sysadmin fixed server role or maybe has the CONTROL SERVER permission).
  • the Server-level configuration option of clr strict security is disabled / 0 (don't do this as it is an unnecessary security risk)
  • the Assembly is signed and you have a corresponding signature-based Login that has been granted the UNSAFE ASSEMBLY permission (please do this)
  • the SHA-512 hash of the Assembly is registered as a "Trusted Assembly" (absolutely never do this as there are numerous problems with it, not to mention that it was never needed in the first place)
  • the Database property of TRUSTWORTHY is ON (don't do this as it is an unnecessary security risk)
  • the Server-level configuration option of clr strict security is disabled / 0 (don't do this as it is an unnecessary security risk)
  • the Assembly is signed and you have a corresponding signature-based Login that has been granted the UNSAFE ASSEMBLY permission (please do this)
  • the SHA-512 hash of the Assembly is registered as a "Trusted Assembly" (absolutely never do this as there are numerous problems with it, not to mention that it was never needed in the first place)
  • the Database property of TRUSTWORTHY is ON (don't do this as it is an unnecessary security risk) and the Login that is the database owner (i.e. same SID used by the [dbo] User) needs to have the UNSAFE ASSEMBLY permission (which it might already have if the owner is sa or a member of the sysadmin fixed server role or maybe has the CONTROL SERVER permission).
  • the Server-level configuration option of clr strict security is disabled / 0 (don't do this as it is an unnecessary security risk)
  • the Assembly is signed and you have a corresponding signature-based Login that has been granted the UNSAFE ASSEMBLY permission (please do this)
  • the SHA-512 hash of the Assembly is registered as a "Trusted Assembly" (absolutely never do this as there are numerous problems with it, not to mention that it was never needed in the first place)
Source Link
Solomon Rutzky
  • 69.5k
  • 8
  • 155
  • 300
Loading