Authentication Between the various components in a distributed setup
-
No that document does not at all describe the situation I’m trying to achieve. It’s still a single kopano-server, they’re just communicating over TCP rather than unix sockets. I’m not talking about distributed kopano with user stores spread out over multiple kopano-servers, it’s a single kopano-server, it’s just running in a different container than in this case, the search container. As for auth going through the certs is what I figured, except how? It’s seemingly not enough that search’s cert is in and the CA being the same. There’s also missing info on compatible certs, such as what cryptos are supported.
As for version, 10.0.3.41 and no, it’s not for commercial deployment. To my mind, Kopano isn’t up to that task since it doesn’t support actual HA, only failover, which just isn’t good enough. Especially when it lacks both fencing and quorum. But that’s not really relevant to this issue.
-
@EtherMan multiple kopano-server instances would just be the next step, but having components such as dagent communicate with the server through tcp is required here as well, see https://documentation.kopano.io/kopanocore_administrator_manual/special_kc_configurations.html#creating-ssl-certificates
And of course can you achieve ha with Kopano, you just need an outside “orchestrator” like for example pacemaker.
-
@EtherMan said in Authentication Between the various components in a distributed setup:
As for auth going through the certs is what I figured, except how? It’s seemingly not enough that search’s cert is in and the CA being the same. There’s also missing info on compatible certs, such as what cryptos are supported.
Whatever your TLS library offers. KC does not care.
Cert guide: https://stash.kopano.io/projects/KC/repos/kopanocore/browse/doc/adminssl.txt . (Each paragraph stands on its own; if you don’t want subjectAltNames, you don’t need it.)
-
Problem with that document @fbartels is that it presupposes the use of a script, that may not at all be what is being used. Such as in k8s, you’d normally use cert-manager and not at all that script. While it’s possible to read that script to get some sample commands, that still doesn’t actually say what it is it’s actually needing.
And no, you can’t get HA with as an example pacemaker in kopano. Not the way the docs claim it at least. A baseline requirement for HA is multiple live nodes that sync together. If a node goes down, it’s not enough that pacemaker now goes in an relaunches on another node which the docs do it. That’s a failover, NOT High Availability. High Availability as a term requires that at worst, only the connections currently active on the failed node is dropped. Any new connections should be redirected to live nodes. Or even better where systems allow for gracefully just having the existing connection just moved to a different node and just have a small lagspike. Having as Kopano does it with having pacemaker start up the service on a different node if it fails… Yea that’s failover, not HA. Just because you can have a HA setup with pacemaker, does not make every setup that happens to use it a HA setup. If you think of it like this. In a large setup, it may actually take upwards an hour or two to actually start a service after even a basic reboot. With kopano’s failover… That means the service would be down for that entire hour. If both nodes are active, with one just pulling sync data from the other… Well then it’s just a matter of detecting when the primary has failed. And that only takes as long as the heartbeats which if you want, you could set to like 10 per second if you wish. Now all that could in theory be solved by having multiple kopano-server instances that are all the same server as far as kopano knows, as in all synced to the same database backend that in itself is HA and so on. But the docs specifically say that is not a valid setup.
@jengelh Ok so it doesn’t care what crypto it is, thank you, but that “guide” doesn’t answer what I asked either. I’m not asking how to generate a certificate or key. I’m well aware of how to do so. I’m asking what format kopano expects it to be in, since there seems to be special requirements as to that. PEM? DER? PKCS12? PKCS7? What uses does the certificates need to have? Subject? Commonnames? DNSes? IPs? uriSANs? emailSANs? min/max durations, is a shared CA required? Or perhaps forbidden? and so on and so on… As well as which of the parts of this needs to go where exactly.
-
EtherMan,
a few weeks ago I did a similar setup, to answer your questions:
Certificates as PEM files are needed, the Subject ‘-subj “/C=XX/ST=State/O=Customer/CN=kopano-mail.customer.xx”’ is the LDAP server name in certificate.
-
@WalterHof Thank you. That’s one part of it solved. I think I already had them as PEM but perhaps something wasn’t. Reissued them and now it works. Now I just need to figure out how to get cert manager to actually manage combined privkey+cert, as well as extracting the pubkey from the cert. Though that’s not for here :)
-
@EtherMan said in Authentication Between the various components in a distributed setup:
to actually manage combined privkey+cert
Simply copy both file into one file.
cat key.pem cert.pem > combined.pem -
@WalterHof That’s not really how Cert Manager works. It’s a bit more complicated than that. Basically you define how you want the cert to look, and cert manager issues you a cert, and private key, and inserts them as secrets in k8s. So to do that, I have to first extract the secret, decode the secret, combine, encode, and insert it back in. It keeps track of pretty much everything for you in that regard. But because kopano needs extracted pubkeys and combined files. Well those are manual so will not get renewed together with the certificate as managed by Cert Manager.
-
@EtherMan said in Authentication Between the various components in a distributed setup:
Ok so it doesn’t care what crypto it is, thank you, but that “guide” doesn’t answer what I asked either. I’m not asking how to generate a certificate or key. I’m well aware of how to do so. I’m asking what format kopano expects it to be in, since there seems to be special requirements as to that. PEM? DER? PKCS12? PKCS7?
The commands in adminssl.txt produce PEM files. adminssl.txt also says the files should contain “PRIVATE KEY” / “CERTIFICATE” markers, which is something you would normally find only in PEM.
What uses does the certificates need to have?
Again, KC mostly does not care. You really just have to please your system’s openSSL default config. There is just hostname (subject) validation, i.e. connecting to https://ab.cd:237/ requires the cert to have “ab.cd” in either CN or SAN.
-
As I said though, the command itself does nothing to answer the question of acceptable formats, and clearly it’s NOT enough that the certs are in a format accepted by openssl, since that accepts other formats as well. It’s also completely incorrect KC doesn’t care about uses, because I’ve been over this now and despite being client auth certs, Kopano requires the certs to be server auth as well, even when being used only for client auth. And no, it doesn’t do subject validation either. It may do it for the server, I have not actually tested that, but this is about the client certs. As in the cert the client is presenting to the server. It’s not connecting fom an URL to have a subject line like that. Anyway, as I’ve said, this part is finished. Search is working. Trying to get konnect and webapp to work is a whole new level of stuff to deal with. It’s in times like these where you try to do anything even just slightly out of the box, that you find out how poorly documented a project like this truly is.
