Lagom: Override default keystore with a user-provided in dev mode

Created on 6 Sep 2018  路  6Comments  路  Source: lagom/lagom

Since Lagom 1.5.0-M3 dev mode supports SSL. When SSL is enabled en dev mode, Lagom internally creates a keystore and adds two keypairs and their certificates into it. The keypairs and certificates are for a self-signed CA and a user certificate emitted by that CA.

It may be interesting to allow users an override mechanism so that instead of creating keypairs and certificates behind scenes they can provide their own CA and server certificate.

(_edit: I've rewritten after https://github.com/lagom/lagom/issues/1577#issuecomment-419006930)

help wanted

Most helpful comment

@TimMoore this is useful in several scenarios. But take these for example:

  • having a better control of certificates allows 3rd party teams to trust the fake certificates. Imagine a CI environment with certificate override where mobile app developers can test their apps knowing beforehand what CA is used (instead of using a trust-all approach).
  • Lagom's auto-generated CA ad certificate make some assumptions wrt signing algorithm, key lengths, etc... Users with specific requirements might want to provide their custom certificates.

All 6 comments

As of the change we merged yesterday, is the new default to _not_ create the keystore?

https://github.com/lagom/lagom/pull/1573/files#diff-b0570315055c9029853b183c2943bf7aR58

Presumably, this will be in the 1.5.0 milestone?

@ignasi35 @erip can you add a little more context? When/why is this necessary?

@TimMoore this is useful in several scenarios. But take these for example:

  • having a better control of certificates allows 3rd party teams to trust the fake certificates. Imagine a CI environment with certificate override where mobile app developers can test their apps knowing beforehand what CA is used (instead of using a trust-all approach).
  • Lagom's auto-generated CA ad certificate make some assumptions wrt signing algorithm, key lengths, etc... Users with specific requirements might want to provide their custom certificates.

Just to be clear. I think this is a great improvement, but I don't think it should block the release of 1.5.0.

I agree with @ignasi35. I just added the "help wanted" label, so if someone from the community can contribute it as an improvement, it could make it into the 1.5.0 release. The SSL support added in 1.5.0 is still somewhat incomplete, and mainly exists to support gRPC integration. More thorough support for SSL will be planned in the future (or can be contributed sooner by members of the community).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ignasi35 picture ignasi35  路  4Comments

TimMoore picture TimMoore  路  8Comments

TimMoore picture TimMoore  路  7Comments

ignasi35 picture ignasi35  路  6Comments

ignasi35 picture ignasi35  路  8Comments