In case you need a server to reproduce the bug with, try connecting to uniapps.uni-rostock.de with arbitrary domain name, username and password.
I am rather sure that this server uses a cert signed by an itermediate CA (because they do it for other services such as HTTP as well.) I tried to verify using openssl's s_client tool:
# openssl s_client -connect uniapps.uni-rostock.de:3389
[…]
Certificate chain
0 s:/C=DE/ST=Mecklenburg-Vorpommern/L=Rostock/O=Universitaet Rostock/OU=ITMZ/CN=rds1.uni-rostock.de
i:/C=DE/O=Universitaet Rostock/OU=Rechenzentrum/CN=Uni Rostock CA - <email address hidden>
1 s:/C=DE/O=Universitaet Rostock/OU=Rechenzentrum/CN=Uni Rostock CA - <email address hidden>
i:/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01
2 s:/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01
i:/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
[…]
In case you need a server to reproduce the bug with, try connecting to uniapps. uni-rostock. de with arbitrary domain name, username and password.
I am rather sure that this server uses a cert signed by an itermediate CA (because they do it for other services such as HTTP as well.) I tried to verify using openssl's s_client tool:
# openssl s_client -connect uniapps. uni-rostock. de:3389 ST=Mecklenburg- Vorpommern/ L=Rostock/ O=Universitaet Rostock/ OU=ITMZ/ CN=rds1. uni-rostock. de DE/O=Universita et Rostock/ OU=Rechenzentru m/CN=Uni Rostock CA - <email address hidden> O=Universitaet Rostock/ OU=Rechenzentru m/CN=Uni Rostock CA - <email address hidden> DE/O=DFN- Verein/ OU=DFN- PKI/CN= DFN-Verein PCA Global - G01 O=DFN-Verein/ OU=DFN- PKI/CN= DFN-Verein PCA Global - G01 DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
[…]
Certificate chain
0 s:/C=DE/
i:/C=
1 s:/C=DE/
i:/C=
2 s:/C=DE/
i:/C=
[…]