Hello Duc, I agree that JKS format is a pain to create and is a barrier to adoption.
Note to mention that JKS use is deprecated and that JKS is considered a propretary format. But rather than replacing it, I wonder if the approach of handling both the JKS format and the key+cert format would not be better (and avoid a breaking change...). By handling both: - We avoid a breaking change for existing james deployments - We enable JKS sick people to migrate away from it What it could look like today <imapservers> <imapserver enabled="true"> <jmxName>imapserver-ssl</jmxName> <bind>0.0.0.0:993</bind> <connectionBacklog>200</connectionBacklog> <tls socketTLS="true" startTLS="false"><keystore>file://conf/keystore</keystore> <secret>james72laBalle</secret> <provider>org.bouncycastle.jce.provider.BouncyCastleProvider</provider></tls></imapserver> </imapservers> Or be a bit more like what you expect... <imapservers> <imapserver enabled="true"> <jmxName>imapserver-ssl</jmxName> <bind>0.0.0.0:993</bind> <connectionBacklog>200</connectionBacklog> <tls socketTLS="true" startTLS="false"><privateKeyFile>file://conf/private.key</keystore> <certificateKeyFile>file://conf/crets.crt</secret><provider>org.bouncycastle.jce.provider.BouncyCastleProvider</provider> </tls></imapserver> </imapservers> Would this be addressing your concerns? Regards, Benoit On 27/08/2021 12:22, Đức Nguyễn wrote: > Hi guys > > > > Recently I’ve been configuring James in Kubernetes deployment. > > When it comes to add certificates for James IMAP/ SMTP, I found that the > configuration requires extra step – which is not convenient for general > users: > > > > *In Virtual machine environment:* > > 1. James > > - Generate, request Certificates ( in crt + key format) > > - Use keytool to create a .jks keystore file > > - Add .jks file to config folder path. > > Reference link: https://james.apache.org/server/3/config-ssl-tls.html > > > > > > 2. Oher Mailing apps (Postfix, Zimbra, Mailu,…): > > - Generate, request Certificates ( in crt + key format) > > - Add both files to designed folder path. > > Reference links: > > - Postfix: > https://www.ssldragon.com/blog/install-an-ssl-certificate-on-postfix/ > > - Zimbra: > https://www.thesslstore.com/knowledgebase/ssl-install/install-ssl-certificate-zimbra-mail-server/ > > > > *In Kubernetes environment* – ( I’m using cert-manager > <https://cert-manager.io/docs/> to request and issue LE certificates ) > > > > Kubernetes manage certificates crt + key format in *kind: Secret* > > - *apiVersion*: v1 > > - *kind*: Secret > > - *metadata*: > > - *name*: secret-tls > > - *type*: kubernetes.io/tls > > - *data*: > > - *# the data is abbreviated in this example* > > - *tls.crt*: | > > - MIIC2DCCAcCgAwIBAgIBATANBgkqh ... > > - *tls.key*: | > > - MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... > > > > Other apps immediately benefits from this approach, they can simply add > cert by request Kubernetes secret: > > secret: > > items: > > - key: tls.crt > > path: cert.pem > > - key: tls.key > > path: key.pem > > secretName: mail-example-com-letsencrypt-ssl > > https://vadosware.io/post/serving-email-on-kubernetes-with-mailu/ > > https://www.tauceti.blog/posts/run-postfix-in-kubernetes/#requesting-tls-certificate > > > > On the contrary, James users (me) are struggling with SSL because of JKS > format. > > The configuration is do-able but complicated for general users: > > - Extract the private key from *tls.key* > > - Extract the issued certificates from *kind: CertifticateRequest* > > - Use openssl to create a KeyStore in PKCS12. > > - Use keytool to convert it to JKS. > > - Add .jks file to config folder path. > > https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/#download-the-certificate-and-use-it > > https://kubernetes.io/docs/reference/kubectl/jsonpath/ > > > > *Conclusion: * > > With Kubernetes and containers have become virtually synonymous with > cloud-native development, Apache James needs to adapt quickly and catch up > with others. > > JKS keystore is an old topic but I’m bringing this back because the change > is necessary. > > > > Regards, > > Duc Nguyen > > DevOps Engineer >
