Happy New Year !
Did anybody get the TLS connection working for rich clients e.g. embedded in Notes in a docker(-compose) Sametime V12 envoirnment ?
https://help.hcltechsw.com/sametime/12/admin/securing_connections_between_community_clients.html?hl=tls
I have added the envoirnmental information to the docker-compose.yml & verified community-mux-pod can access the .p12 file.
HCL support created SAME-46474 for this but I can't believe I am the first one trying to establish a TLS connection with a rich client ?
Kind regards,
Jan
Happy New Year Jan,
Have you opened a support case?
In the documentation, I am not sure if this is the correct keystore filename - /local/sametimemuxdata/keystore.p12.
In Docker, we also support the global TLS scope (where you have one keystore and one truststore for all Sametime services to use). My expertise is in k8s, so I'm not sure of the exact details in how to accomplish that. It might be a workaround, we can get you in touch with one of our support engineers.
You might also have a look at this article: https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0101354
The same limitation on the p12 format applies to all Sametime services, not just the LDAP one. You can try recreating your trust store with the parameter -J-Dkeystore.pkcs12.legacy when you create it using keytool.
Lastly, what were the settings in the stconfig.nsf file have been moved to StCommunityConfig.xml. Have you configured it?
Please get in contact with us so that we can help you.
Thanks,
Casey Toole, HCL
I have already created a case which lead to mentioned SAME-46474 which made me create this thread.
I was using OpenSSL with command "openssl pkcs12 -export -in cert.crt -inkey cert.key -certfile ca.crt -out sametime.p12" which usually works in all applications.
That is the log part printed by mux-pod:
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : ---- Thread ID: 140213166353280
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : Creating TLS configuration with prefix [STMUX_TLS_]
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : Trust file [] type [] password [] stash file [] Key file [/local/sametimemuxdata/keystore.p12] type [p12] password [*******] stash file []
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : Key label []
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : FIPS mode [0]
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : Security level [0]
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : Protocol version min [0x0] max [0x0]
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : Cipher suites []
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : Request client certificate [0]
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : Initializing OpenSSL
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : opensslLoad, full [true] use namespace [true]
stmux 2023-01-04 11:22:41.971 INFO 23 --- 140213166353280 : Loading [/opt/hcl/sametimemux/STOpenSSL/libcrypto.so]
stmux 2023-01-04 11:22:41.974 INFO 23 --- 140213166353280 : Loading [/opt/hcl/sametimemux/STOpenSSL/libssl.so]
stmux 2023-01-04 11:22:41.990 INFO 23 --- 140213166353280 : OpenSSL compiled version [OpenSSL 1.0.2zd-fips 15 Mar 2022] crypto version [OpenSSL 1.0.2zd-fips 15 Mar 2022]
stmux 2023-01-04 11:22:41.990 INFO 23 --- 140213166353280 : Creating [41] locks
stmux 2023-01-04 11:22:41.990 INFO 23 --- 140213166353280 : OpenSSL initialized
stmux 2023-01-04 11:22:41.990 INFO 23 --- 140213166353280 : Setting FIPS-140 compliance to [0]
stmux 2023-01-04 11:22:41.990 INFO 23 --- 140213166353280 : Setting protocol version min [0x0301:TLSv1] max [0x0303:TLSv1.2]
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
stmux 2023-01-04 11:22:50.608 ERROR 23 --- 140213166353280 : Exception handler: the end.
I found something: Eventhough documentation says "STI__Debug__" should be used you must use only 1 "_" => "STI_Debug" & "STI_Config" is now set in mux.env & my pod is running without errors !
Still TLS is not working, but 1 step closer.
The same problem for a keystore created with "keytool" & legacy-parameter instead of "openssl".
Hi Jan,
There are definitely supposed to be two underscores between STI, then the section name, then two underscores after the section name. If you don't have two underscores, its probably not reading the parameters, and not "enabling" TLS, allowing the container to start. We would know for sure if you had some logs.
If you remote into the Community container, you can examine the sametime.ini there to see if the parameters are correctly placed and in the correct section. Also the logs should indicate if TLS is being set, you'll see some prints like the one you posted. Like this:
Creating TLS configuration with prefix [STMUX_TLS_]
Do you still see these prints after changing the parameters?
I would put the parameters back with the two underscores, then try using keytool to create your keystore, per the article I shared. You can create a self signed cert to test with. If the keystore is not in this "legacy format" then Sametime can't read it. (It took me a week to figure this out when I first installed ST12.)
Link to article: https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0101354
like this:
keytool -importcert -storetype PKCS12 -keystore keystore.p12 -storepass thepassword -alias stmux -file subject.cer -noprompt -J-Dkeystore.pkcs12.legacy
Thanks,
Casey
Thank you for the ideas !Sadly this also did not help :(
The resulting sametime.in in the pod looks fine:
[Config]
VPMX_CAPACITY=20000
ST_TLS_KEY_STORE_PASSWORD=mypw
ST_TLS_KEY_STORE_FILE=/local/sametimemuxdata/keystorekt.p12
ST_TLS_KEY_STORE_TYPE=p12
[Capacity]
(i choosed the name keystorekt.p12, that is no typo)
Again only "bad_alloc" error message in log. Also interesting: After starting the docker-pod a folder with the keystore reference is created in /opt/STMeetingServer:
...I think the whole docker-part is just not tested & verified by HCL and I need to wait as I was told in case CS0363640....
And if you are looking for logs - these are the only lines that come from the mux-pod:
stmux 2023-01-04 16:23:49.979 INFO 18 --- 140049405479808 : Starting standalone Mux -- update sametime.ini and exit
stmux 2023-01-04 16:23:49.979 INFO 18 --- 140049405479808 : Updating config files with environment vars
stmux 2023-01-04 16:23:49.979 INFO 18 --- 140049405479808 : UPDATING config entry - iniFileName = </local/sametimemuxdata/sametime.ini> section = <Debug> key = <VPMX_PORT>
stmux 2023-01-04 16:23:49.979 INFO 18 --- 140049405479808 : UPDATING config entry - iniFileName = </local/sametimemuxdata/sametime.ini> section = <Config> key = <ST_TLS_KEY_STORE_PASSWORD>
stmux 2023-01-04 16:23:49.979 INFO 18 --- 140049405479808 : UPDATING config entry - iniFileName = </local/sametimemuxdata/sametime.ini> section = <Config> key = <ST_TLS_KEY_STORE_FILE>
stmux 2023-01-04 16:23:49.979 INFO 18 --- 140049405479808 : UPDATING config entry - iniFileName = </local/sametimemuxdata/sametime.ini> section = <DEBUG> key = <VP_TRACE_FILE>
stmux 2023-01-04 16:23:49.979 INFO 18 --- 140049405479808 : UPDATING config entry - iniFileName = </local/sametimemuxdata/sametime.ini> section = <DEBUG> key = <VP_TRACE_ALL>
stmux 2023-01-04 16:23:49.979 INFO 18 --- 140049405479808 : UPDATING config entry - iniFileName = </local/sametimemuxdata/sametime.ini> section = <Config> key = <VPMX_CAPACITY>
stmux 2023-01-04 16:23:50.049 INFO 18 --- 140049405479808 : UPDATING config entry - iniFileName = </local/sametimemuxdata/sametime.ini> section = <Debug> key = <VPMX_TLS_PORT>
stmux 2023-01-04 16:23:50.049 INFO 18 --- 140049405479808 : UPDATING config entry - iniFileName = </local/sametimemuxdata/sametime.ini> section = <Debug> key = <VPMX_DISABLE_CONFIGURATION_UPDATE>
stmux 2023-01-04 16:23:50.049 INFO 18 --- 140049405479808 : UPDATING config entry - iniFileName = </local/sametimemuxdata/sametime.ini> section = <Config> key = <ST_TLS_KEY_STORE_TYPE>
stmux 2023-01-04 16:23:50.477 INFO 18 --- 140049370818304 : Terminated
stmux 2023-01-04 16:23:50.572 INFO 23 --- 139798514707328 : Starting Mux
stmux 2023-01-04 16:23:50.572 INFO 23 --- 139798514707328 : Started, version SAMETIME10.0_20221109-2225, Hotfix AAZI-9KBHLC Defect 19593 Loading Libraries: Threadsafe - SAMETIME10.0_20221109-2225 StLib - SAMETIME10.0_20221109-2225 Socket - SAMETIME10.0_20221109-2225 Vpk - SAMETIME10.0_20221109-2225
stmux 2023-01-04 16:23:50.645 INFO 23 --- 139798514707328 : Mux(REMOTE) configured to login to following servers:192.168.128.15 (community)
stmux 2023-01-04 16:23:50.645 INFO 23 --- 139798514707328 : Mux configured to Http Server on ip=192.168.128.21, port=80
stmux 2023-01-04 16:23:50.645 INFO 23 --- 139798514707328 : Mux configured to max of 200 favoured http connections
stmux 2023-01-04 16:23:50.645 INFO 23 --- 139798514707328 : Mux configured to manage persistent channels to following services: 49 53 57
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : CBR initialization:
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : CBR entry: url=/meetingcbr, serverIp=192.168.128.21, port=8081
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : CBR entry: url=/broadcastcbr, serverIp=192.168.128.21, port=8083
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Mux configured to thresholdInterval=10, thresholdMessageCounter=5000, thresholdCreateCounter=2000, thresholdSendCounter=2000
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Mux configured to trust all client IP addresses
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Mux configured to Load Balance server designation, recalculating balance every 100 clients connections.
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : ---- Thread ID: 139798514707328
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Creating TLS configuration with prefix [STMUX_TLS_]
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Trust file [] type [] password [] stash file [] Key file [/local/sametimemuxdata/keystorekt.p12] type [p12] password [*******] stash file []
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Key label []
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : FIPS mode [0]
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Security level [0]
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Protocol version min [0x0] max [0x0]
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Cipher suites []
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Request client certificate [0]
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Initializing OpenSSL
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : opensslLoad, full [true] use namespace [true]
stmux 2023-01-04 16:23:50.646 INFO 23 --- 139798514707328 : Loading [/opt/hcl/sametimemux/STOpenSSL/libcrypto.so]
stmux 2023-01-04 16:23:50.648 INFO 23 --- 139798514707328 : Loading [/opt/hcl/sametimemux/STOpenSSL/libssl.so]
stmux 2023-01-04 16:23:50.701 INFO 23 --- 139798514707328 : OpenSSL compiled version [OpenSSL 1.0.2zd-fips 15 Mar 2022] crypto version [OpenSSL 1.0.2zd-fips 15 Mar 2022]
stmux 2023-01-04 16:23:50.701 INFO 23 --- 139798514707328 : Creating [41] locks
stmux 2023-01-04 16:23:50.701 INFO 23 --- 139798514707328 : OpenSSL initialized
stmux 2023-01-04 16:23:50.701 INFO 23 --- 139798514707328 : Setting FIPS-140 compliance to [0]
stmux 2023-01-04 16:23:50.701 INFO 23 --- 139798514707328 : Setting protocol version min [0x0301:TLSv1] max [0x0303:TLSv1.2]
stmux 2023-01-04 16:23:58.362 ERROR 23 --- 139798514707328 : Exception handler: the end.
Regards,
Jan
@Casey Toole
I think this issue of the keystore type is super important. I had problems that had me spinning my wheels for weeks on both my truststore (for backend LDAP) and my keystore (for Notes Client to mux) on a fresh install. Finally I tried creating them with JDK 1.8 and magically everything started working!
This must be the missing piece of the puzzle on why keystores and truststores created by JDK 1.8 worked and JDK 11, 17 did not. Do you think? My case number (now closed) was CS0359533 if you're curious.
Thanks for the feedback @Ben Erickson , I'll do some testing and open up a case internally if needed.
The volume-mapping in docker-compose.yml was wrongly configured from my side.
I mixed local-fs/pod-fs
volumes:
- /keystore.p12:/local/sametimemuxdata/keystore.p12
So I put my keystore.p12 to /local/sametimemuxdata/ on the server. In this case I should have used:
volumes:
- /local/sametimemuxdata/keystore.p12:/local/sametimemuxdata/keystore.p12
Is it working now Jan?
I set up mine in Kubernetes this morning and it worked fine.