Spring Cloud Config 2022.0.4 : No decryption for FailsafeTextEncryptor. Did you configure the keystore correctly?

Hello,

Describe the bug Spring Boot 3.1.4, Spring Cloud 2022.0.4

Run this Config Server : https://github.com/mpalourdio/ConfigServer Run this Spring Cloud Gateway : https://github.com/mpalourdio/ProxyServer

This fails with

***************************
APPLICATION FAILED TO START
***************************

Description:

Failed to bind properties under 'spring.cloud.config.password' to java.lang.String:

    Property: spring.cloud.config.password
    Value: "{cipher}12c545c7e569d579c0b205bfebeef99dcbf07c0d079b4035ce2980ef6ef2301e"
    Origin: class path resource [application.properties] - 22:30
    Reason: java.lang.UnsupportedOperationException: No decryption for FailsafeTextEncryptor. Did you configure the keystore correctly?

Action:

Update your application's configuration

Sample See above, clone both and mvn spring-boot:run

Observations

Going back to 2022.0.2 as version in https://github.com/mpalourdio/ProxyServer works. Fails with 2022.0.3 too.

Comment From: mpalourdio

Hi,

Just updated to 2023.0.1 but the error still remains. What works to have symmetric OK, is exporting the env var, ie,

export ENCRYPT_KEY=mykey The property encrypt.key=mykey still has no effect and leads to the exception.

Whereas the doc seems to indicate that the property should be ok : https://docs.spring.io/spring-cloud-config/docs/current/reference/html/#_key_management

I have updated the repositories from OP to latest versions.

Please see : https://github.com/mpalourdio/ProxyServer/blob/6d85ca9469848bf44d1893fecc8ac6cb6f0fe5b2/src/main/resources/application.properties#L14

Comment From: ryanjbaxter

Try adding

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-bootstrap</artifactId>
        </dependency>

and set encrypt.key in bootstrap.properties. It is needed during bootstrap and that is why the environment variable works.

Comment From: mpalourdio

Sure, this used to work (and will work) like prior the introduction of spring.config.import. But all our apps had been refactored to remove the need of the bootstrap in Spring Cloud, and it has worked until 2022.0.2. All versions after 2022.0.2 have failed with this configuration, and I didn't see any deprecation/removal warning.

Also the documentation still states this point

The Config Server can use a symmetric (shared) key or an asymmetric one (RSA key pair). The asymmetric choice is superior in terms of security, but it is often more convenient to use a symmetric key since it is a single property value to configure in the application.properties.

To configure a symmetric key, you need to set encrypt.key to a secret String (or use the ENCRYPT_KEY environment variable to keep it out of plain-text configuration files).

This notice is in the documentation too :

If you include spring-cloud-starter-bootstrap on the classpath or set spring.cloud.bootstrap.enabled=true as a system property, you will need to set encrypt.key in bootstrap.properties

If we reintroduce the spring-cloud-starter-bootstrap dependency, we need to go back to spring.cloud.config.uri vs spring.config.import too.

Something has changed somewhere in SC, but i don't know where. Thanks for your feedback

Comment From: mpalourdio

So i have tested with reintroducing spring-cloud-starter-bootstrap and moving the encrypt.key to bootstrap.properties. As stated, it did not work until I change spring.config.import to the good ol' spring.cloud.config.uri. (or forcing spring.config.import to optional)

But once gain, it has been broken exactly from 2022.0.3. If you point me to a piece of code that may have lead to this breaking change, I'd be happy to give it a look.

Comment From: ryanjbaxter

I believe I have a way where we can support this, but technically your use case here is not valid. Having the key and the encrypted value in the same file is insecure.

Comment From: mpalourdio

Don't get me wrong. If the behavior that used to work, and does not work anymore, is intended, no need to workaround with it, please. We'll change on our side.

I was just surprised when it stopped to work because it worked for years without any notice, and is documented as is.

Thanks again.

Comment From: ryanjbaxter

I think there might be some other valid scenarios that may also not work so I think the fix is needed