Best way to package liberty app with default java truststore (cacerts)
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I'm packaging a liberty application which works with Db2. When we run locally, we configure certificates to secure the connection from app to db.
Now I'm trying to package the same application for use with the Db2 on Cloud service, and I'm having trouble with the SSL configuration.
I think I could create a truststore and add the digicert root CA to it and package that with the app, but instead I was leaning toward just using the JDK's built-in cacerts (because we also have restrictive firewall rules preventing outbound connections to other hosts).
I found extremely relevant discussion at https://github.com/OpenLiberty/open-liberty/issues/4377, but I can't seem to find a nice way to specify the path to the JDK's cacert store in a portable way.
I tried setting it as follows:
<keyStore id="defaultKeyStore" location="${env.JAVA_HOME}/jre/lib/security/cacerts"/>
But for some reason it doesn't resolve the environment variable. Why?
Additionally, this will only work when the JAVA_HOME is set to a JDK (like in development). In our containers, we don't have that and so we don't want the jre part in the path.
Whats the simplest/easiest way to tell Liberty just to use the JDK's default truststore (in a portable way)?
websphere-liberty open-liberty
asked Jan 4 at 18:28
lmsurprenantlmsurprenant
6751616
add a comment |
I'm packaging a liberty application which works with Db2. When we run locally, we configure certificates to secure the connection from app to db.
Now I'm trying to package the same application for use with the Db2 on Cloud service, and I'm having trouble with the SSL configuration.
I think I could create a truststore and add the digicert root CA to it and package that with the app, but instead I was leaning toward just using the JDK's built-in cacerts (because we also have restrictive firewall rules preventing outbound connections to other hosts).
I found extremely relevant discussion at https://github.com/OpenLiberty/open-liberty/issues/4377, but I can't seem to find a nice way to specify the path to the JDK's cacert store in a portable way.
I tried setting it as follows:
<keyStore id="defaultKeyStore" location="${env.JAVA_HOME}/jre/lib/security/cacerts"/>
But for some reason it doesn't resolve the environment variable. Why?
Additionally, this will only work when the JAVA_HOME is set to a JDK (like in development). In our containers, we don't have that and so we don't want the jre part in the path.
Whats the simplest/easiest way to tell Liberty just to use the JDK's default truststore (in a portable way)?
websphere-liberty open-liberty
asked Jan 4 at 18:28
lmsurprenantlmsurprenant
6751616
add a comment |
I'm packaging a liberty application which works with Db2. When we run locally, we configure certificates to secure the connection from app to db.
Now I'm trying to package the same application for use with the Db2 on Cloud service, and I'm having trouble with the SSL configuration.
I think I could create a truststore and add the digicert root CA to it and package that with the app, but instead I was leaning toward just using the JDK's built-in cacerts (because we also have restrictive firewall rules preventing outbound connections to other hosts).
I found extremely relevant discussion at https://github.com/OpenLiberty/open-liberty/issues/4377, but I can't seem to find a nice way to specify the path to the JDK's cacert store in a portable way.
I tried setting it as follows:
<keyStore id="defaultKeyStore" location="${env.JAVA_HOME}/jre/lib/security/cacerts"/>
But for some reason it doesn't resolve the environment variable. Why?
Additionally, this will only work when the JAVA_HOME is set to a JDK (like in development). In our containers, we don't have that and so we don't want the jre part in the path.
Whats the simplest/easiest way to tell Liberty just to use the JDK's default truststore (in a portable way)?
websphere-liberty open-liberty
asked Jan 4 at 18:28
lmsurprenantlmsurprenant
6751616
I'm packaging a liberty application which works with Db2. When we run locally, we configure certificates to secure the connection from app to db.
Now I'm trying to package the same application for use with the Db2 on Cloud service, and I'm having trouble with the SSL configuration.
I think I could create a truststore and add the digicert root CA to it and package that with the app, but instead I was leaning toward just using the JDK's built-in cacerts (because we also have restrictive firewall rules preventing outbound connections to other hosts).
I found extremely relevant discussion at https://github.com/OpenLiberty/open-liberty/issues/4377, but I can't seem to find a nice way to specify the path to the JDK's cacert store in a portable way.
I tried setting it as follows:
<keyStore id="defaultKeyStore" location="${env.JAVA_HOME}/jre/lib/security/cacerts"/>
But for some reason it doesn't resolve the environment variable. Why?
Additionally, this will only work when the JAVA_HOME is set to a JDK (like in development). In our containers, we don't have that and so we don't want the jre part in the path.
Whats the simplest/easiest way to tell Liberty just to use the JDK's default truststore (in a portable way)?
websphere-liberty open-liberty
websphere-liberty open-liberty
asked Jan 4 at 18:28
lmsurprenantlmsurprenant
6751616
asked Jan 4 at 18:28
lmsurprenantlmsurprenant
6751616
asked Jan 4 at 18:28
lmsurprenantlmsurprenant
6751616
asked Jan 4 at 18:28
lmsurprenantlmsurprenant
6751616
asked Jan 4 at 18:28
lmsurprenantlmsurprenant
6751616
6751616
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I did this just yesterday and my recommendation would be this configuration:
<ssl id="defaultSSLConfig" trustStoreRef="myTrustStore"/>
<keyStore id="myTrustStore" location="${java.home}/lib/security/cacerts" password="changeit" />
In my case I was using https inbound to my Liberty server using the generated self signed certs (I was doing development testing) and if I set defaultKeyStore pointing at cacerts inbound ssl was broken because it doesn't contain a server cert I could use. Instead I just updated the default ssl configuration to use cacerts as a trust store and left the keystore as is.
I used ${java.home} because it will always be there (well unless Java gets rid of this system variable, but I suspect that won't always be the case). Liberty's server script has a number of ways to work out the Java location so it doesn't need JAVA_HOME as an env var. I'm guessing in your case JAVA_HOME isn't set as an env var, but the system property will always be there.
answered Jan 4 at 18:45
AlasdairAlasdair
2,381918
Thanks, that is exactly what I was looking for. In my case, I wanted to keep our base image unmodified and so I layered on the cloud configuration via a configDropin. Works locally on my mac and I think it will work well in our containers as well.
– lmsurprenant
Jan 4 at 18:59
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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%2f54044281%2fbest-way-to-package-liberty-app-with-default-java-truststore-cacerts%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I did this just yesterday and my recommendation would be this configuration:
<ssl id="defaultSSLConfig" trustStoreRef="myTrustStore"/>
<keyStore id="myTrustStore" location="${java.home}/lib/security/cacerts" password="changeit" />
In my case I was using https inbound to my Liberty server using the generated self signed certs (I was doing development testing) and if I set defaultKeyStore pointing at cacerts inbound ssl was broken because it doesn't contain a server cert I could use. Instead I just updated the default ssl configuration to use cacerts as a trust store and left the keystore as is.
I used ${java.home} because it will always be there (well unless Java gets rid of this system variable, but I suspect that won't always be the case). Liberty's server script has a number of ways to work out the Java location so it doesn't need JAVA_HOME as an env var. I'm guessing in your case JAVA_HOME isn't set as an env var, but the system property will always be there.
answered Jan 4 at 18:45
AlasdairAlasdair
2,381918
Thanks, that is exactly what I was looking for. In my case, I wanted to keep our base image unmodified and so I layered on the cloud configuration via a configDropin. Works locally on my mac and I think it will work well in our containers as well.
– lmsurprenant
Jan 4 at 18:59
add a comment |
I did this just yesterday and my recommendation would be this configuration:
<ssl id="defaultSSLConfig" trustStoreRef="myTrustStore"/>
<keyStore id="myTrustStore" location="${java.home}/lib/security/cacerts" password="changeit" />
In my case I was using https inbound to my Liberty server using the generated self signed certs (I was doing development testing) and if I set defaultKeyStore pointing at cacerts inbound ssl was broken because it doesn't contain a server cert I could use. Instead I just updated the default ssl configuration to use cacerts as a trust store and left the keystore as is.
I used ${java.home} because it will always be there (well unless Java gets rid of this system variable, but I suspect that won't always be the case). Liberty's server script has a number of ways to work out the Java location so it doesn't need JAVA_HOME as an env var. I'm guessing in your case JAVA_HOME isn't set as an env var, but the system property will always be there.
answered Jan 4 at 18:45
AlasdairAlasdair
2,381918
Thanks, that is exactly what I was looking for. In my case, I wanted to keep our base image unmodified and so I layered on the cloud configuration via a configDropin. Works locally on my mac and I think it will work well in our containers as well.
– lmsurprenant
Jan 4 at 18:59
add a comment |
I did this just yesterday and my recommendation would be this configuration:
<ssl id="defaultSSLConfig" trustStoreRef="myTrustStore"/>
<keyStore id="myTrustStore" location="${java.home}/lib/security/cacerts" password="changeit" />
In my case I was using https inbound to my Liberty server using the generated self signed certs (I was doing development testing) and if I set defaultKeyStore pointing at cacerts inbound ssl was broken because it doesn't contain a server cert I could use. Instead I just updated the default ssl configuration to use cacerts as a trust store and left the keystore as is.
I used ${java.home} because it will always be there (well unless Java gets rid of this system variable, but I suspect that won't always be the case). Liberty's server script has a number of ways to work out the Java location so it doesn't need JAVA_HOME as an env var. I'm guessing in your case JAVA_HOME isn't set as an env var, but the system property will always be there.
answered Jan 4 at 18:45
AlasdairAlasdair
2,381918
I did this just yesterday and my recommendation would be this configuration:
<ssl id="defaultSSLConfig" trustStoreRef="myTrustStore"/>
<keyStore id="myTrustStore" location="${java.home}/lib/security/cacerts" password="changeit" />
In my case I was using https inbound to my Liberty server using the generated self signed certs (I was doing development testing) and if I set defaultKeyStore pointing at cacerts inbound ssl was broken because it doesn't contain a server cert I could use. Instead I just updated the default ssl configuration to use cacerts as a trust store and left the keystore as is.
I used ${java.home} because it will always be there (well unless Java gets rid of this system variable, but I suspect that won't always be the case). Liberty's server script has a number of ways to work out the Java location so it doesn't need JAVA_HOME as an env var. I'm guessing in your case JAVA_HOME isn't set as an env var, but the system property will always be there.
answered Jan 4 at 18:45
AlasdairAlasdair
2,381918
answered Jan 4 at 18:45
AlasdairAlasdair
2,381918
answered Jan 4 at 18:45
AlasdairAlasdair
2,381918
answered Jan 4 at 18:45
AlasdairAlasdair
2,381918
2,381918
Thanks, that is exactly what I was looking for. In my case, I wanted to keep our base image unmodified and so I layered on the cloud configuration via a configDropin. Works locally on my mac and I think it will work well in our containers as well.
– lmsurprenant
Jan 4 at 18:59
add a comment |
Thanks, that is exactly what I was looking for. In my case, I wanted to keep our base image unmodified and so I layered on the cloud configuration via a configDropin. Works locally on my mac and I think it will work well in our containers as well.
– lmsurprenant
Jan 4 at 18:59
Thanks, that is exactly what I was looking for. In my case, I wanted to keep our base image unmodified and so I layered on the cloud configuration via a configDropin. Works locally on my mac and I think it will work well in our containers as well.
– lmsurprenant
Jan 4 at 18:59
Thanks, that is exactly what I was looking for. In my case, I wanted to keep our base image unmodified and so I layered on the cloud configuration via a configDropin. Works locally on my mac and I think it will work well in our containers as well.
– lmsurprenant
Jan 4 at 18:59
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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%2f54044281%2fbest-way-to-package-liberty-app-with-default-java-truststore-cacerts%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
