Certificate Strategy

[hogstrom]

From @hogstrom on September 12, 2018 13:7

Management

We need to document the certs we are shipping, where they are located and their expiration date

Copied from original issue: zowe/zac#27

[hogstrom]

Could use Let's Encrypt as a way of installing.

[hogstrom]

From @1000TurquoisePogs on September 19, 2018 13:44

The certs for the UI portion are located within https://github.com/zowe/zlux-example-server/tree/master/config
As the name suggests, the example server is an implementation of the server. It could be renamed to something better to state it's "zowe default" nature, but regardless this is where we keep certs and keys for HTTPS. They're just self-signed.
Since lets encrypt allows for free signed certs as a result of you proving that your host is legitimate, we can't put lets encrypt certs in the git repo but our installer could prompt the user as to:

1. whether they'd like to provide their own certs (and point to where they are),
2. if they'd like to go through the lets encrypt option (I believe it requires an internet connection, so not everyone can do this)
3. use the shipped self-signed certs

[hogstrom]

From @1000TurquoisePogs on October 24, 2018 17:3

I found acme.sh and greenlock to be the two most promising tools that work with Let's Encrypt (really, an implementer of the ACME protocol).
acme.sh didn't work on the mainframe.
greenlock as a stand-alone tool expects the network ports to be 443 and 80.
So my latest idea is to use greenlock-express as a library to make a small custom nodejs server that runs as a small tool for a few seconds to generate a valid HTTPS cert that I assume could then be copied into a place that is usable by all of our servers.

There's still one big problem with all of this: Let's Encrypt is designed for internet-connected servers, because a server proves its legitimacy by showing that the publicly accessible server is under your control. This doesn't seem like it will help LAN access which is our common use case.

[hogstrom]

I have the same problem with my servers … they can access the Internet but the Internet cannot access them. I suspect all customers have faced this issue though and already have certs … anyone have first hand knowledge? We could ask on the on boarding channel and ask users that have deployed Zowe what their approach is ?

Matt Hogstrom
matt@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook https://www.facebook.com/matt.hogstrom LinkedIn https://linkedin.com/in/mhogstrom Twitter https://twitter.com/hogstrom

From Lord of the Rings, when Frodo decides to leave the Fellowship and go to Mordor alone . . . Frodo: “I wish the ring had never come to me. I wish none of this had happened.” Gandalf: “So do all who live to see such things. But it is not for them to decide. All you have to do is decide what to do with this time that is given to you.”

On Oct 24, 2018, at 1:04 PM, Sean Grady notifications@github.com wrote:

I found acme.sh and greenlock to be the two most promising tools that work with Let's Encrypt (really, an implementer of the ACME protocol).
acme.sh didn't work on the mainframe.
greenlock as a stand-alone tool expects the network ports to be 443 and 80.
So my latest idea is to use greenlock-express as a library to make a small custom nodejs server that runs as a small tool for a few seconds to generate a valid HTTPS cert that I assume could then be copied into a place that is usable by all of our servers.

There's still one big problem with all of this: Let's Encrypt is designed for internet-connected servers, because a server proves its legitimacy by showing that the publicly accessible server is under your control. This doesn't seem like it will help LAN access which is our common use case.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub zowe/zac#27 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ACxXp5oQvrePBYAiJwTnaAnjRGTvbyNAks5uoJ2ZgaJpZM4WlWFI.

[hogstrom]

My thoughts here are we should have all services that are shipped as part of Zowe use the same self-signed certificate which should be a project wide resource. We could try and provide an easy button for certs but the reality is that all mainframe customers have their own process for managing and adding certs so the work we do here is probably only useful to a small number of people. Thoughts ? I suggest we go with a single self-signed cert (we can put it in the CI/CD repo) and move on for now.

[hogstrom]

From @1000TurquoisePogs on October 31, 2018 14:49

Update: ZLC voted on that it would be time better spent to focus on making it easy to apply 1 certificate to all of zowe for ease of allowing users to provide their own signed certs. The default (self-signed) cert could be this one, since it's valid for 2 years and says "Zowe":
https://github.com/zowe/zlux-example-server/blob/master/config/server.key
https://github.com/zowe/zlux-example-server/blob/master/config/server.cert

[hogstrom]

Moving to CI/CD and assigning it to @jackjia-ibm

[hogstrom]

@jackjia-ibm Can you review this and incorporate into the build process ?

[jackjia-ibm]

@hogstrom I have updates from Petr and this is what in plan:

The APIML is going to have certificate management for the service that are used by it.

There are several possibilities for services that are integrated with APIML (southbound access):

• Zowe components will get a certificate for them generated and signed by APIML CA (certificate authority) during Zowe installation – it should be split by component like zLUX, APIML, Atlas etc. so a security problem in one component will be limited just to that component
• Services that will be added to Zowe and APIML after the Zowe installation can:
  • Request new certificate for them so they can integrate to APIML
  • Import they certificate or CA that have signed it to the Zowe APIML truststore

The access to API Gateway by users (e.g. via Zowe Desktop) and services outside of APIML (northbound) can use two certificates:

• The certificate signed by APIML CA – then then the clients (browser, HTTP clients in services) needs to trust the APIML CA certificate
• The API Gateway can use a certificate that is signed by an external CA and already trusted by the clients

The work on it is in progress right now.

---

After we have the CA ready, I will help on publishing the root CA for users to download and import, and also embed the require steps into build pipeline.