Andrzej Wójcik (Tigase) opened 10 years ago
-
I finished refactoring of SSLContextContainer in Tigase XMPP Server by:
-
spliting loading and handling of SSL certificates to
CertificateContainerclass -
separation of
root@SSLContextContainer@ responsible for cachingSSLContextinstances when no customTrustManageris passed -
creation of
SSLContextContainerinstances perConnectionManager@, which will hold @SSLContextinstances when customTrustManageris passed (if not it will forward request torootinstance of @SSLContextContainer@)
Due to that implementation of each class is simpler and easier to maintain and better fits requirements. From now on it will be possible to change configuration of
SSLContextused by particular implementation ofConnectionManagerby providing custom implementation ofSSLContextContainerfor particular connection manager.I also removed
SNISSLContextContainerfor version 7.2.0-SNAPSHOT as I moved this feature toCertificateContainterand added new configuration option:basic-conf/sni-disable[B]=trueto disable SNI support.
Still need to adjust PEMSSLContextContainer implementation in
tigase-extrasproject. -
| Type |
Task
|
| Priority |
Normal
|
| Assignee | |
| RedmineID |
3610
|
| Version |
tigase-server-8.0.0
|
| Estimation |
0
|
| Spent time |
0
|
We need to refactor SSLContextContainer and classes using it as some components (ie. S2S, C2S, WS2S) needs to have different configuration/instances of SSLContext for same domain.
Currently there is implementation inside SSLContextContainer which keeps all this cached instances and ensures they are separated but this is complicated already and it will be better to refactor SSLContextContainer and it's usage to make it simpler and better.
During refactoring I think we need to forget about singleton instance of SSLContextContainer and split it so we will get:
one singleton instance keeping server certificates for each hosted domains
many SSLContext caching instances inside each component which requires to retrieve SSLContext