Spring Boot SSL works only on RestController Contstructor
up vote
2
down vote
favorite
Since I'm moving old architecture to a new Spring Boot solution I'm implementing the calls through @RestController.
Now, the FE needs to pass data to my @RestController which handles it, and make an old RPC-call to an old SoapWs.
The Rpc Ws-Endpoint uses Https, and needs a certificate.
So I've put everything in the Keystore and set the System.Properties accordingly.
Now the interesting part.
If I define the System properties in main spring boot Application Startup Class:
@Component
public class ApplicationStartup
implements ApplicationListener<ApplicationReadyEvent> {
@Override
public void onApplicationEvent(final ApplicationReadyEvent event) {
System.setProperty("javax.net.ssl.keyStore","/cert/clientkeystore.jks");
System.setProperty("javax.net.ssl.trustStore","/cert/clientkeystore.jks");
System.setProperty("javax.net.debug","ssl");
System.setProperty("javax.net.ssl.keyStorePassword","changeit");
System.setProperty("javax.net.ssl.trustStorePassword","changeit");
}
I can see them in the @RestController. I've checked them through System.getProperties(...) method and they are where they're supposed to be.
But the call to remote-rpc ws gives Handshake failure.
If set variables in the @RestController constructor....it works!
That's the only change.
I'm astonished, no clues at all.
java spring spring-boot rpc
|
show 4 more comments
up vote
2
down vote
favorite
Since I'm moving old architecture to a new Spring Boot solution I'm implementing the calls through @RestController.
Now, the FE needs to pass data to my @RestController which handles it, and make an old RPC-call to an old SoapWs.
The Rpc Ws-Endpoint uses Https, and needs a certificate.
So I've put everything in the Keystore and set the System.Properties accordingly.
Now the interesting part.
If I define the System properties in main spring boot Application Startup Class:
@Component
public class ApplicationStartup
implements ApplicationListener<ApplicationReadyEvent> {
@Override
public void onApplicationEvent(final ApplicationReadyEvent event) {
System.setProperty("javax.net.ssl.keyStore","/cert/clientkeystore.jks");
System.setProperty("javax.net.ssl.trustStore","/cert/clientkeystore.jks");
System.setProperty("javax.net.debug","ssl");
System.setProperty("javax.net.ssl.keyStorePassword","changeit");
System.setProperty("javax.net.ssl.trustStorePassword","changeit");
}
I can see them in the @RestController. I've checked them through System.getProperties(...) method and they are where they're supposed to be.
But the call to remote-rpc ws gives Handshake failure.
If set variables in the @RestController constructor....it works!
That's the only change.
I'm astonished, no clues at all.
java spring spring-boot rpc
isn't there a typo? C:/ prefix is missing from trustStore path
– David Szalai
Nov 9 at 14:16
No it's just me amending things to publish code. Anyways corrected...thanks!
– Black.Jack
Nov 9 at 14:19
It is possible that ApplicationReadyEvent is too late to register such values, as SSLContext might already be initialized. Try putting them in @PostConstruct of the component.
– David Szalai
Nov 9 at 14:29
Yep that's more or less my "constructor approach". But other than specify every time I build the bean, I would fine-grained control the keystore.on a specific call.
– Black.Jack
Nov 9 at 14:39
I don't really understand what you mean by that. Why do you want to be able to change the trustStore for every call? Anyways, you can create multiple instances of docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html, and depending on what library you use for the remote call, inject an instance into that.
– David Szalai
Nov 9 at 14:49
|
show 4 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Since I'm moving old architecture to a new Spring Boot solution I'm implementing the calls through @RestController.
Now, the FE needs to pass data to my @RestController which handles it, and make an old RPC-call to an old SoapWs.
The Rpc Ws-Endpoint uses Https, and needs a certificate.
So I've put everything in the Keystore and set the System.Properties accordingly.
Now the interesting part.
If I define the System properties in main spring boot Application Startup Class:
@Component
public class ApplicationStartup
implements ApplicationListener<ApplicationReadyEvent> {
@Override
public void onApplicationEvent(final ApplicationReadyEvent event) {
System.setProperty("javax.net.ssl.keyStore","/cert/clientkeystore.jks");
System.setProperty("javax.net.ssl.trustStore","/cert/clientkeystore.jks");
System.setProperty("javax.net.debug","ssl");
System.setProperty("javax.net.ssl.keyStorePassword","changeit");
System.setProperty("javax.net.ssl.trustStorePassword","changeit");
}
I can see them in the @RestController. I've checked them through System.getProperties(...) method and they are where they're supposed to be.
But the call to remote-rpc ws gives Handshake failure.
If set variables in the @RestController constructor....it works!
That's the only change.
I'm astonished, no clues at all.
java spring spring-boot rpc
Since I'm moving old architecture to a new Spring Boot solution I'm implementing the calls through @RestController.
Now, the FE needs to pass data to my @RestController which handles it, and make an old RPC-call to an old SoapWs.
The Rpc Ws-Endpoint uses Https, and needs a certificate.
So I've put everything in the Keystore and set the System.Properties accordingly.
Now the interesting part.
If I define the System properties in main spring boot Application Startup Class:
@Component
public class ApplicationStartup
implements ApplicationListener<ApplicationReadyEvent> {
@Override
public void onApplicationEvent(final ApplicationReadyEvent event) {
System.setProperty("javax.net.ssl.keyStore","/cert/clientkeystore.jks");
System.setProperty("javax.net.ssl.trustStore","/cert/clientkeystore.jks");
System.setProperty("javax.net.debug","ssl");
System.setProperty("javax.net.ssl.keyStorePassword","changeit");
System.setProperty("javax.net.ssl.trustStorePassword","changeit");
}
I can see them in the @RestController. I've checked them through System.getProperties(...) method and they are where they're supposed to be.
But the call to remote-rpc ws gives Handshake failure.
If set variables in the @RestController constructor....it works!
That's the only change.
I'm astonished, no clues at all.
java spring spring-boot rpc
java spring spring-boot rpc
edited Nov 12 at 14:58
tom1299
618
618
asked Nov 9 at 13:43
Black.Jack
1,09221428
1,09221428
isn't there a typo? C:/ prefix is missing from trustStore path
– David Szalai
Nov 9 at 14:16
No it's just me amending things to publish code. Anyways corrected...thanks!
– Black.Jack
Nov 9 at 14:19
It is possible that ApplicationReadyEvent is too late to register such values, as SSLContext might already be initialized. Try putting them in @PostConstruct of the component.
– David Szalai
Nov 9 at 14:29
Yep that's more or less my "constructor approach". But other than specify every time I build the bean, I would fine-grained control the keystore.on a specific call.
– Black.Jack
Nov 9 at 14:39
I don't really understand what you mean by that. Why do you want to be able to change the trustStore for every call? Anyways, you can create multiple instances of docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html, and depending on what library you use for the remote call, inject an instance into that.
– David Szalai
Nov 9 at 14:49
|
show 4 more comments
isn't there a typo? C:/ prefix is missing from trustStore path
– David Szalai
Nov 9 at 14:16
No it's just me amending things to publish code. Anyways corrected...thanks!
– Black.Jack
Nov 9 at 14:19
It is possible that ApplicationReadyEvent is too late to register such values, as SSLContext might already be initialized. Try putting them in @PostConstruct of the component.
– David Szalai
Nov 9 at 14:29
Yep that's more or less my "constructor approach". But other than specify every time I build the bean, I would fine-grained control the keystore.on a specific call.
– Black.Jack
Nov 9 at 14:39
I don't really understand what you mean by that. Why do you want to be able to change the trustStore for every call? Anyways, you can create multiple instances of docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html, and depending on what library you use for the remote call, inject an instance into that.
– David Szalai
Nov 9 at 14:49
isn't there a typo? C:/ prefix is missing from trustStore path
– David Szalai
Nov 9 at 14:16
isn't there a typo? C:/ prefix is missing from trustStore path
– David Szalai
Nov 9 at 14:16
No it's just me amending things to publish code. Anyways corrected...thanks!
– Black.Jack
Nov 9 at 14:19
No it's just me amending things to publish code. Anyways corrected...thanks!
– Black.Jack
Nov 9 at 14:19
It is possible that ApplicationReadyEvent is too late to register such values, as SSLContext might already be initialized. Try putting them in @PostConstruct of the component.
– David Szalai
Nov 9 at 14:29
It is possible that ApplicationReadyEvent is too late to register such values, as SSLContext might already be initialized. Try putting them in @PostConstruct of the component.
– David Szalai
Nov 9 at 14:29
Yep that's more or less my "constructor approach". But other than specify every time I build the bean, I would fine-grained control the keystore.on a specific call.
– Black.Jack
Nov 9 at 14:39
Yep that's more or less my "constructor approach". But other than specify every time I build the bean, I would fine-grained control the keystore.on a specific call.
– Black.Jack
Nov 9 at 14:39
I don't really understand what you mean by that. Why do you want to be able to change the trustStore for every call? Anyways, you can create multiple instances of docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html, and depending on what library you use for the remote call, inject an instance into that.
– David Szalai
Nov 9 at 14:49
I don't really understand what you mean by that. Why do you want to be able to change the trustStore for every call? Anyways, you can create multiple instances of docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html, and depending on what library you use for the remote call, inject an instance into that.
– David Szalai
Nov 9 at 14:49
|
show 4 more comments
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53226876%2fspring-boot-ssl-works-only-on-restcontroller-contstructor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
isn't there a typo? C:/ prefix is missing from trustStore path
– David Szalai
Nov 9 at 14:16
No it's just me amending things to publish code. Anyways corrected...thanks!
– Black.Jack
Nov 9 at 14:19
It is possible that ApplicationReadyEvent is too late to register such values, as SSLContext might already be initialized. Try putting them in @PostConstruct of the component.
– David Szalai
Nov 9 at 14:29
Yep that's more or less my "constructor approach". But other than specify every time I build the bean, I would fine-grained control the keystore.on a specific call.
– Black.Jack
Nov 9 at 14:39
I don't really understand what you mean by that. Why do you want to be able to change the trustStore for every call? Anyways, you can create multiple instances of docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html, and depending on what library you use for the remote call, inject an instance into that.
– David Szalai
Nov 9 at 14:49