You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Duc Nguyen <mi...@linagora.com> on 2021/08/27 04:37:23 UTC
About James .jks keystore for SSL/TLS
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-certificat
e-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-cer
tificate
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 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
Re: About James .jks keystore for SSL/TLS
Posted by "btellier@apache.org" <bt...@apache.org>.
Hello Raphael, Duc,
This weekend I did put together a proof of concept regarding alternative
PEM key usage.
This looks something like this:
<tls socketTLS="true" startTLS="false">
<privateKey>file://conf/private.nopass.key</privateKey> <certificates>file://conf/certs.self-signed.csr</certificates> </tls>
You can find a Proof of concept PR there:
https://github.com/apache/james-project/pull/626
I also created a dedicated ticket:
https://issues.apache.org/jira/browse/JAMES-3639
@rouazana @duc does it answers your concerns?
I mentionned this ticket in the most related ticket:
https://issues.apache.org/jira/browse/JAMES-3215
(https://issues.apache.org/jira/browse/JAMES-3209is IMO barely related
as it discuss setting up NGinx as an encryption proxy...).
We had some discussion on this topic, but sadly inside Linagora. (#1549)
As it is very relevant to the ongoing dicussion, I am going to disclose
its content (creadits go mostly to Raphael Ouazana and Matthieu
Baechler, I merely relay their sayings...) We discussed PKCS12 support
(ascii armored so that can be passed as environment variables / k8s
secrets), java enforcing keystore being an implementation details - and
thus PEM key support.
Some key concepts where expressed as well like removing all
cryptographic keys from default configuration, including demo images.
What is very interesting was a proposal to have auto-generation
configuration option to ensure both convenient and secure set-up for
demo image - we likely should consider implementing this too.
Regards,
Benoit
On 27/08/2021 21:42, Raphaël Ouazana-Sustowski wrote:
> Hello,
>
> Le 27/08/2021 à 06:37, Duc Nguyen a écrit :
>
>> 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.
>
> I agree, we need to review the way we manage keys in James. See for
> example this ticket which mentions also the issue:
> https://issues.apache.org/jira/browse/JAMES-3209
>
> I'm in favor of getting rid of keystore in favor of PEM format (or at
> least allowing both).
>
> Regards,
> Raphaël.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
Re: About James .jks keystore for SSL/TLS
Posted by "btellier@apache.org" <bt...@apache.org>.
Hello Otto, hello all,
On 28/08/2021 04:37, Otto, Karsten Andreas wrote:
> On 27.08.21 16:42, Raphaël Ouazana-Sustowski wrote:
>> I'm in favor of getting rid of keystore in favor of PEM format (or at
>> least allowing both).
>>
> If at all possible please allow both; in our setup we use the same
> keystore for multiple service endpoints in addition to the mail server.
> It would be inconvenient to require different formats in this case.
I agree let's avoid alienate users, even more when renewal/format
changes could be non trivial (at least to me...).
>
> Also let me point out that we use PCKS#12 keystores (.p12), which is the
> preferred format for newer Java releases. Maybe setting the James
> default for .p12 instead of .jks would be a step in the right direction?
I do agree with this, even more that changing the keystore algorithm is
trivial.
I fully agree making the keystore type configurable. Supporting PKCS12
is definitly a quick and easy win!
This could look something like this:
<tls socketTLS="false" startTLS="false"><keystore>file://conf/keystore</keystore> <keystoreType>PKCS12</keystoreType> <secret>yoursecret</secret> <provider>org.bouncycastle.jce.provider.BouncyCastleProvider</provider><algorithm>SunX509</algorithm> </tls>
Then the self-signed keystore generation becomes:
$ keytool -genkey -alias james -keyalg RSA -storetype PKCS12 -keystore keystore
I did open
https://issues.apache.org/jira/projects/JAMES/issues/JAMES-3638?filter=allissues
as well as https://github.com/apache/james-project/pull/625.
To be fair, I see this as a first step, I would like having an
alternative without keystore.
Regards,
Benoit
>
> Cheers, Karsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: About James .jks keystore for SSL/TLS
Posted by "Otto, Karsten Andreas" <Ka...@akquinet.de.INVALID>.
On 27.08.21 16:42, Raphaël Ouazana-Sustowski wrote:
>
> I'm in favor of getting rid of keystore in favor of PEM format (or at
> least allowing both).
>
If at all possible please allow both; in our setup we use the same
keystore for multiple service endpoints in addition to the mail server.
It would be inconvenient to require different formats in this case.
Also let me point out that we use PCKS#12 keystores (.p12), which is the
preferred format for newer Java releases. Maybe setting the James
default for .p12 instead of .jks would be a step in the right direction?
Cheers, Karsten
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: About James .jks keystore for SSL/TLS
Posted by Raphaël Ouazana-Sustowski <ro...@apache.org>.
Hello,
Le 27/08/2021 à 06:37, Duc Nguyen a écrit :
> 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.
I agree, we need to review the way we manage keys in James. See for
example this ticket which mentions also the issue:
https://issues.apache.org/jira/browse/JAMES-3209
I'm in favor of getting rid of keystore in favor of PEM format (or at
least allowing both).
Regards,
Raphaël.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org