Provide API to disable SSL validation when using RestClient

[hannah23280]

Scenario:
Using RestClient to send an API call to another application via HTTPS, for the purpose of encrypting payload at transportation layer. I do not want any client or server authentication/validation. To that end I observe the following code works. Just call this method in the @PostConstruct of my spring boot main application. It works

*Note: I understood the importance of having SSL validations, but let's not debate why I want to disable such validations. Cos not every projects out in the wild are interested to care about the SSL validations, especially if 2 microservices are interacting with each other via a dedicated link in an isolated, super secured area

At both client and server side

public Boolean disableSSLValidation() throws Exception {
	final SSLContext sslContext = SSLContext.getInstance("TLS");

	sslContext.init(null, new TrustManager[]{new X509TrustManager() {
		@Override
		public void checkClientTrusted(X509Certificate[] x509Certificates, String s) {}

		@Override
		public void checkServerTrusted(X509Certificate[] x509Certificates, String s) {}

		@Override
		public X509Certificate[] getAcceptedIssuers() {
			return new X509Certificate[0];
		}
	}}, null);

	HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory());
	HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
		public boolean verify(String hostname, SSLSession session) {
			return true;
		}
	});

}

At server side (disable client authentication)

server:
  port: 443
  ssl:
    enabled: true
    protocol: TLS
    enabled-protocols: TLSv1.2
    bundle: xxx
    key-alias: demo
spring.ssl.bundle.jks.xxx:
    keystore.type: PKCS12
    keystore.location: file:C:/.../cert_dev.p12   <--have no choice but to generate a keystore file, otherwise during bootup, embedded tomcat server will throw error. Even though this file seems to be useless since i am not interested in any SSL validations
    keystore.password: xxxx

My question is: Can spring-mvc provides an API to do what the aforementioned code is doing (disableSSLValidation) instead of developer having to manually implement it?

[xufeiranfree]

I want to know too.

[bclozel]

Thanks for getting in touch, but it feels like this is a question that would be better suited to Stack Overflow. As mentioned in the guidelines for contributing, we prefer to use the issue tracker only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add some more details if you feel this is a genuine bug.

In this case, RestTemplate, RestClient and WebClient all are API abstractions on top of existing HTTP client libraries. Such configuration depends on the actual library and we cannot provide a unified model for all.

[hannah23280]

Thanks for getting in touch, but it feels like this is a question that would be better suited to Stack Overflow. As mentioned in the guidelines for contributing, we prefer to use the issue tracker only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add some more details if you feel this is a genuine bug.

In this case, RestTemplate, RestClient and WebClient all are API abstractions on top of existing HTTP client libraries. Such configuration depends on the actual library and we cannot provide a unified model for all.

hi, this post is actually for request for enhancement purpose.
if the above disableSslvalidation works for restclient and web client ,(ignoring resttemplate, since it is currently put into maintenance mode), I wonder why not let the framework implement it for us developer? developer can just simply configure via properties to disable SSL validations (or programmatically call an API), rather than having to implement the boilerplate code

[bclozel]

@hannah23280 we are not going to invest here, since such configuration is very low level and specific to the HTTP client. Again, providing a unified approach for this would be very challenging. There are many variations and subtle HTTP client configuration, so it's unlikely we would design an efficient property model. We are declining this enhancement proposal.