Cannot Decrypt Pdf The Password Is Incorrect

[Dunstan Jomphe]

Ive been working on Spring Cloud Config for a while. I have a requirement of securing the config data. As per Spring Cloud Documentation I have configured the server.jks and added to classpath. Now I am able to encrypt and decrypt remote config data.

For making the config server secure I have added Spring Security Starter and assigned credentials (password decrypted). For some reason the application is throwing exceptions that it does not have key store on the classpath. After googling it for a while I found that the keystore should go to bootstrap.yml instead of application.yml. This is also not working, what am I missing here?

I have had this problem. To set symmetric encryption in the latest versions of spring cloud, you just have to set the encrypt.key property in the bootstap.yml(or .properties) with the required key (it is recommended to set the key as an OS environmental variable and reference the variable in your file. This is for more security)

I was facing the same problem from the config client side. To resolve this, I added this dependency in the pom.xml and in bootstarp.properties/bootstrap.yml file, I added encrypt.key property as I was using symmetric encryption.

I am getting the following error when trying to deploy my SSRS reports on our SQL 2008 R2 Server "The report server cannot decrypt the symmetric key used to access sensitive or encrypted data in a report server database...". Most of the solutions on the Web suggest to delete the encryption keys, then reconfigure the datasources. I am still a beginner in SSRS, Is there another solution to fix this issue, Thanks

I ran into this with a Microsoft Dynamics CRM 2016 Reporting Extensions Setup after changing the SQL Server Reporting Services account from services.msc. This is because the Microsoft Dynamics CRM 2016 Reporting Extensions Setup requires a non-local service account. -us/library/hh699754.aspx The key trigger here that is likely the root cause seen in the Haasan's question was the changing of the SQL Server Reporting Services service account without backing up the encryption key. While what he did with deleting encryption keys worked, it has drawbacks of losing that encryption information and if possible, you should use the steps below to revert back to the original service account user and then change the service account using the steps documented below and in the reference article.

The long story here is that when changing the SQL Server Reporting Services account, you need to do that from the SQL Server Services Reporting Manager as that will prompt you to back up the Symmetric encryption key that SQL Server Reporting Services uses and restore it with the new service account user.

The Report Server service uses the symmetric key to access the encrypted data in a report server database. This symmetric key is encrypted by using an asymmetric public key that corresponds to the computer and the user account that is used to run the Report Server service. When you change the user account that is used to run the Report Server service, the report server cannot use the asymmetric public key to decrypt the symmetric key. Therefore, the Report Server service cannot use the symmetric key to access the data from the report server database.

Automatically adds the new account to the report server group created on the local computer. This group is specified in the access control lists (ACLs) that secure Reporting Services files. Automatically updates the login permissions on the SQL Server Database Engine instance used to host the report server database. The new account will be added to the RSExecRole. The database login for the old account will not be removed automatically. Be sure to remove accounts that are no longer in use. For more information, see Administer a Report Server Database (SSRS Native Mode) in SQL Server Books Online. Granting database permissions to new service account only occurs if you configured the report server database connection to use the service account in the first place. If you configured the report server database connection to use a domain user account or a SQL Server database login, the connection information is not affected by the service account update. Automatically updates the encryption key to include the profile information of the new account.

If like in my scenario, you happen to know what the previous service account user was, the fix is to change the SQL Server Report Service account user back to the originally specified account and then to use the SQL Server Reporting Services Reporting Manager to change the account and to ensure that you backup the encryption key as that process automates the restore of the encryption key when the new service account user is set.

-us/kb/842421 - You receive an error message in the Reporting Services trace log when you restart the Report Server service after you change the user account that is used to run the Report Server service (This is an old KB article, but the general problem and resolution still applies with newer versions of SQL Reporting Services)

I ran into this issue after moving the ReportServer and ReportServerTempDB from a working server to a different environment running Reporting Services. Deleting the encryption keys was not an option and I knew the password used to create the encryption key, so I took a backup of the key from the working server and restored it using Reporting Services Configuration Manager on the new environment. Refreshed the page and the error went away.

We have a database with column-level encryption. We need to migrate data (using the "Export" functionality) from this database to a target database. In order to use the same key structure, we created backups of the Database Master Key and Certificate, and restored those on the target database. There seems to be no restore functionality for the Symmetric Key, so we used the same CREATE script we used on the source database.

2. In your sample script, you are not opening your database master key before opening the user key (I realize you may be doing that and simply didn't post that step). The database master key must be opened before you can open any other keys. If the database master key has been encrypted using the Service Master Key, then it will be opened automatically for you when you attempt to open other keys. Otherwise, it must be specifically opened first using one of the passwords under which it has been encrypted. The database master key may be encrypted many times with many passwords, and may additionally be encrypted using the Service Master key. Compare the results of the following query when run in both source and target databases:

...specifically, key 101 (the database master key). If there there is a row in that result for the database master key where crypt_type_desc = ENCRYPTION BY MASTER KEY, but not in the target, you simply need to encrypt the database master key in the target using the Service Master Key:

First, thank you for the link. I was not using the KEY_SOURCE or IDENTITY_VALUE values when creating my Symmetric Key. Once I utilized those keywords I was able to create the same keys on all of our databases, regardless of server. That was a tremendous help.

1) Entering data into the encrypted field from a business application attached to the database. The code that reads/writes to the database opens the Symmetric Key and uses encrypt/decrypt when accessing the encrypted values. This works perfectly.

2) I encrypted two databases, then exported a table with encrypted data to the second database, and was able to decrypt the data through SSMS just by opening the Symmetric Key and using the decrypt function. This worked fine as well.

In all three scenarios, I was able to decrypt, either through the business application or through SSMS. However, when I tested restoring a database on one server from a backup of a database from a different server, two things happened:

My question then is under what circumstances does the Database Master Key need to be opened? In testing this through the business application, the DMK open statement was not included in the code, and it worked fine. It appears that by crossing servers I'm generating this DMK error, but I can't be sure that is the only issue.

I hope this makes sense. If not, I'm happy to clarify. And I sure hope someone can help with this because the code is about to be promoted to full testing and I'd hate to have to pull it back if this can be resolved this quickly.

It must always be opened. However, if that key has been encrypted by the Service Master Key, then it will be opened automatically, and you won't need to issue an OPEN MASTER KEY statement. Look in the original location to see of the Database Master Key has been encrypted using the Service Master Key (see query in my previous post).

The Service Master Key is unique to each SQL Server instance. If you restore a database to the same instance, the Service Master key will work in the newly-restored database because it does not change, and resides outside of the databases.

So, if the Database Master Key has been encrypted using the Service Master (instance) Key in one location, and then you copy that database somewhere else, the Service Master Key of the new instance will be unable to open the Database Master Key, until you re-encrypt the Database Master Key using the new location's Service Master Key (the second script from my previous post, run it in the database in the new location).

Thanks Eddie. Your explanation makes perfect sense, because we didn't see this error until our test scenario of restoring a database on one server with a backup file from another server. All our other testing worked fine without running the script to open the master key, and once we ran the script the restored database worked fine as well.

Thank you so much for all your assistance. This morning I deployed encryption over our entire testing base, and so far, so good. So your quick responses allowed me to hit my deadline. I hope I can return the favor some day.

3a8082e126