You can use the openssl command to decode and print certificate contents
openssl -noout -text -in example.com.pem
You should be able to find the DNS names listed on the cert in the Subject Alternative Name: sectilon.
You can't use different certificates for the same website (*). Use a public certificate, internal clients will trust it just fine.
(*) There are workarounds, but they are quite cumberstome and you shouldn't use them unless absolutely required.
It could be done, but you probably don't want to.
It's technically possible for a TLS certificate to be used as both a server certificate and a client certificate. The TLS certificate for this very site has its key usage set that way, for instance.
But the server which requires a client certificate does so to authenticate the client. So it will want a ...
It looks that you placed certificate files inside Public html diretory:
This may be security measure to prevent of using such certificates.
Move cert diretory one level up:
mv /var/www/html/cert /var/www/
set the readable for apache user (Ubuntu and debian systems use user www-data)
chown -R apache /var/www/cert
Change the ...
The question is not totally correct. It is not SSL certificate may be intercepted. The SSL certificate of a website is a publicly available entity.
The SSL connection may be intercepted, especially when your client's certificate has different hash from your own, as you confirmed in your case.
Such interception is common in the large corporate IT ...
I would agree with the other comments that if a simpler setup works for you, go simple. But to answer your original question, you can have multiple site bindings - you would setup one with the internal IP address and internal certificate, and another with the external/DMZ IP and public certificate. I would also suggest defining a host name per binding and ...
If you do not control TLS clients trust, and you do not issue certificates from any private PKI they may have, you are left with the generally trusted certificate authorities. Does not matter who issues them as long as the clients are configured to trust their CA.
Major problem with "wildcard" certs is that it is trusted for everything in *.example.com. ...
That error message generally indicates a formatting error in the certificate file. You need to make sure all of your -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines are there, that there's no trailing white space after them or any piece of the certs, no unnecessary blank lines, etc.
It's likely something got messed up when you concatenated.