Andrzej Wójcik (Tigase) opened 6 days ago
-
-
@wojtek What do you think would be the best approach. Right now we have certificates stored by the main alias of the certificate but also used by
Subject Alternative Namesdomains loaded and overwritten at random. -
Wojciech Kapcia (Tigase) added "Related" Customers/atom#301 3 days ago
-
-
Hmm... this is basically due to trying to have nice-and-automatic things. And SAN + widlcards are just throwing spanner into the weels. AFAIR this is mostly due to concurrency issue where connector port could be open before the certificates are all loaded and self-signed certificate would be generated)
In general self-signed certificas most of the time only cause issues and it would be nice to actually get rid of them altogether…
We do need self-signed given that we now require the certs. Generating one only for default/"main" installatino domain (and ignoring for the rest) sounds very good.
I would also avoid storing any self-signed certificate in the repository (which in this case should help even without previous step) and avoid overriding any certificates in CertificateContainer with self-signed ones altogether (slightly smarter logic there). AFAIR I already made it so that the self-signed should not be generated if the proper certificate is only expired (both are invalid in the grand scheme of things but still, expired one slightly less than self-signed IMHO).
We could also add an option to enable/disable generating self-signed certificates automatically (on by default, but handy in certain deploymenst that are already strapped on; alternatively off by default and generate the self-signed cert only when using installer?)
I'm not sure that ad-hoc that requires specifying vhosts explicitly would be that great (certificate duplication, having to maintain the correct list in certbot, etc)
All in all:
- don't store any self-signed certificates in the repository
- generate self-signed cert only for the main/default VHost and no other domain
-
Previous Value Current Value Open
In Progress
-
Please review my changes.
I've took a slightly different approach. I've added a mechanism to decide which certificate is "more important". I've decided (and I think we agree on that) that self-signed certificate are lowest priority. Then certificates with matching name, then with domain in the SAN (with exception if matching name certificate is not valid any more and SAN covering this domain is valid).
With that in place and minor change to "remove" from use wildcard certificates that are self-signed if those are not used for "primary" domain (those autogenerated by the server), I've achieved a working solution that looks to be stable and correctly selecting SSL certificates.
I've also added an option
removeSelfSignedUnusedCertsthat can detect unused self-signed certificates (those that were replaced by other certs using SAN) that when enabled could remove those certificates from the repository.I also think we are still missing an option to remove certificate (adhoc action). Right now we can update the certificate but we cannot remove it (could be useful for domains that are no longer in use/no longer hosted).
-
Name Previous Value Current Value State
In Progress
In QA
Assignee
andrzej.wojcik
wojtek
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| Version |
none
|
| Sprints |
n/a
|
| Customer |
n/a
|
Tigase XMPP Server loads certificates and uses them for "assigned domain" (domain for which certificate was uploaded) and domain for which domain is "good for" (
Subject Alternative Names). That causes an issue is we have 2 certificates for the same domain, ie. we have automatically generated certificate for domaintest.example.com(self-signed), while after a while we upload certificate forexample.comthat hastest.example.cominSubject Alternative Names.After that Tigase XMPP Server will use certificate that was added later (that would be
example.comcertificate). That would be somehow correct.However, after the restart of the server, Tigase XMPP Server may load "self-signed" certificate for domain
test.example.comafter loadingexample.comcertificate (that is valid fortest.example.comas well). That results in a self-signed certificate being returned by the server even if valid certificate is available.I think this issue was partially started with changes from
Improve loading certificates and updating them later on #1080that started overriding certificates if a new certificate had a value forSubject Alternative Names.As we already made a switch and now require (by default) a valid SSL certificate, it would be reasonable to resolve this issue.
The easiest solution, would be to "delete" old/previous certificates that matches domain or alt domain when a new certificate is provided. However, with support for wildcards and ie. multiple domains/subdomains being supported by more than one certificate that may cause issues with random assignment of certificate for domain. That could be resolved by forcing users to pass domain for which certificate should be used (manually) and only use this certificate for a single domain but it wouldn't allow users to upload a single certificate for multiple domains at once (or even subdomains).
We could also keep track of the order in which certificates were upload and always use newest certificates (apply them in order of upload).
While we are at it, I would like to remove generation of self-signed certificates with exception of "default" certificate. That means that unless certificate would be uploaded for a domain only "default" certificate would be used. That would allow us to get rid of self-signed certificates generated automatically and switch to just a single certificate that would be self-signed and manager by the server. Others if needed, would need to be managed by the user/