If you want to verify the certificate chain all certificates of the chain need to be available in some way and at least the final CA root certificate should be on your server too. Let’s check how the chain looks like (taken from the transferred certificates):
Certificate chain
0 s:C = DE, ST = Sachsen, L = Dresden, O = Technische Universitaet Dresden, OU = Fakultaet Mathematik, CN = www.math.tu-dresden.de
i:C = DE, ST = Sachsen, L = Dresden, O = Technische Universitaet Dresden, CN = TU Dresden CA
1 s:C = DE, O = Technische Universitaet Dresden, OU = ZIH, CN = TU Dresden CA - G02, emailAddress = pki@tu-dresden.de
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
3 s:C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
i:C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
So lets have a closer look on the certificates provided by the server.
- The first certificate (CN = www.math.tu-dresden.de) has been issued by “CN = TU Dresden CA”.
- The subject of the second transferred certificate is “CN = TU Dresden CA - G02”!!
- …
Due to the fact that a certificate chain relies on subject/issuer CN string pairs on which the verification hashes are build, you will see that there is a discrepancy between the issuer of the server certificate (CN = TU Dresden CA) and the provided next intermediate certificate (**CN = TU Dresden CA - G02).
A browser is very often able to use its own certificate cache to verify it, but on a Linux server you need to provide that certificates in the CA path.
So my conclusion is, that TU Dresden provides an invalid chain certificate which causes the problem if you try to access that page from your server.
