You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm in the process of setting up a stack with wildduck, haraka, and zone-mta for a new mail server on a kubernetes cluster; it's going quite well, but I ran into a snag when I went to set up certificates to use with haraka TLS. Kubernetes has cert-manager which can handle getting letsencrypt certificates for domains which I have been doing; those are stored as a "tls" type secret in kubernetes -- it's just a standard, nothing really special.
The challenge is that the simplest way to map those into a container -- the least extra configuration needed -- puts each "secret" in a directory with "tls.crt" and "tls.key"; however I try to use those I can't use more than one certificate pair at a time without adding some kind of special handler.
Describe the solution you'd like
I'd like to see one or both of two options (ideally both):
In the "certificates" directory if there are any directories found containing exactly one .crt and one .key file (or maybe specifically named tls.crt and tls.key it should load them the same way it would load if it found a pem file with both in the certificates directory
If you specify multiple keys and certs using key[]= and cert[]= it should support having each be a different domain using SNI -- to be honest I expected that to be the functionality when I read the documentation, I'm not sure why else you'd need to have multiple, but from what I can see in the code it doesn't support that and when I tried it (before reading the code) it didn't work.
Describe alternatives you've considered
Right now I'm only using a single TLS certificate for a single domain; the best option I can think of to make this work on a longer term basis is to write something which will detect when the LE certificate secret is updated and create an additional certificate (or possibly add a key to that secret) for the .pem file with both in it, then map those .pem files into the container. This isn't ideal and would be a pain, but it should work.
It would also help if haraka could detect when the certificate files changed and update, but I can work around that by ensuring the pod gets restarted at least every month or so.
Additional context
It might even make sense to just go ahead and support it on a more specific level, e.g. kubernetes-specific flags; in that case you could pull them from environment variables or just have a "kubernetes secrets" path for the root of where you mounted them all or something. For more information about tls secrets in kuberenetes see https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets
I'd be willing to help with this, but I'm not familiar with the codebase and dont' know how you'd want it implemented.
The text was updated successfully, but these errors were encountered:
In the "certificates" directory if there are any directories found containing exactly one .crt and one .key file (or maybe specifically named tls.crt and tls.key it should load them the same way it would load if it found a pem file with both in the certificates directory
This seems quite reasonable to me.
It would also help if haraka could detect when the certificate files changed and update
Is your feature request related to a problem? Please describe.
I'm in the process of setting up a stack with wildduck, haraka, and zone-mta for a new mail server on a kubernetes cluster; it's going quite well, but I ran into a snag when I went to set up certificates to use with haraka TLS. Kubernetes has
cert-manager
which can handle getting letsencrypt certificates for domains which I have been doing; those are stored as a "tls" type secret in kubernetes -- it's just a standard, nothing really special.The challenge is that the simplest way to map those into a container -- the least extra configuration needed -- puts each "secret" in a directory with "
tls.crt
" and "tls.key
"; however I try to use those I can't use more than one certificate pair at a time without adding some kind of special handler.Describe the solution you'd like
I'd like to see one or both of two options (ideally both):
.crt
and one.key
file (or maybe specifically namedtls.crt
andtls.key
it should load them the same way it would load if it found a pem file with both in the certificates directorykey[]=
andcert[]=
it should support having each be a different domain using SNI -- to be honest I expected that to be the functionality when I read the documentation, I'm not sure why else you'd need to have multiple, but from what I can see in the code it doesn't support that and when I tried it (before reading the code) it didn't work.Describe alternatives you've considered
Right now I'm only using a single TLS certificate for a single domain; the best option I can think of to make this work on a longer term basis is to write something which will detect when the LE certificate secret is updated and create an additional certificate (or possibly add a key to that secret) for the .pem file with both in it, then map those .pem files into the container. This isn't ideal and would be a pain, but it should work.
It would also help if haraka could detect when the certificate files changed and update, but I can work around that by ensuring the pod gets restarted at least every month or so.
Additional context
It might even make sense to just go ahead and support it on a more specific level, e.g. kubernetes-specific flags; in that case you could pull them from environment variables or just have a "kubernetes secrets" path for the root of where you mounted them all or something. For more information about tls secrets in kuberenetes see https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets
I'd be willing to help with this, but I'm not familiar with the codebase and dont' know how you'd want it implemented.
The text was updated successfully, but these errors were encountered: