How to check the Domain and Subject Alt Names listed on the SSL/TLS Certificate for your TAS for VMs installation
Article ID: 297950
Updated On:
Products
Issue/Introduction
Environment
Resolution
Checking Cert Info
If you wish to check what domain names you have loaded in your Cert, you can run the following command:
openssl req -in your.csr -noout -text
The output will display details on your domain.
Checking Cert Info via API
To retrieve information about your Cert via your API, run one of the following commands:
openssl s_client -connect api.system.10.x.x.x:443 or openssl s_client -connect api.system.yourdomain.com:443 -state -debug >ssl-debug.txt
Check Cert Info via a Browser
Browse to you Domain api.your-domain.com in your browser, click on the lock icon, and check the Cert's details.
Checking your Subject Alternative Name (SAN)
You may need to check that your Cert has all the necessary SAN's loaded. To do this, run the following command:
echo -n | openssl s_client -connect "api.systemDomain.example.com:443" | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text | grep "DNS:"
You will see something similar to the following output:
DNS:*.uaa.systemDomain.example.com, DNS:*.login.systemDomain.example.com, DNS:*.systemDomain.example.com
Additional Information
Internally Signed Certs/Self-Signed Certs
A Self-Signed CA is not publicly trusted but is configured to trust all of the company's computers or networks. This is a common situation for large companies. If your environment is not publicly facing you can use Self-Signed Certs. Configuring your private browsers to accept your own Certificates as trusted.
Publicly Signed Certs
If you are serving Public internet traffic you should use Publicly signed Certs generated using a CA (Certification Authority). This will prevent browsers generating certificate error when accessing your apps. A CA issues digital certificates that are trusted by default in browsers. So when accessing your App's users will not get any SSL/Certificate errors.
Please refer to the following links for more information on Configuring Certificates of PCF:
- https://docs.pivotal.io/pivotalcf/1-8/opsguide/security_config.html
- http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html
- https://docs.oracle.com/javase/6/docs/technotes/guides/net/proxies.html
- http://docs.pivotal.io/pivotalcf/1-9/adminguide/securing-traffic.html
- https://docs.pivotal.io/pivotalcf/1-7/opsguide/custom-load-balancer.html
- https://discuss.pivotal.io/hc/en-us/articles/230613767-How-To-Trust-Public-IP-Ranges-as-Trusted-Proxies-in-Elastic-Runtime
Additional Information
Internally Signed Certs/Self-Signed Certs
A Self-Signed CA is not publicly trusted but is configured to trust all of the company's computers or networks. This is a common situation for large companies. If your environment is not publicly facing you can use Self-Signed Certs. Configuring your private browsers to accept your own Certificates as trusted.
Publicly Signed Certs
If you are serving Public internet traffic you should use Publicly signed Certs generated using a CA (Certification Authority). This will prevent browsers generating certificate error when accessing your apps. A CA issues digital certificates that are trusted by default in browsers. So when accessing your App's users will not get any SSL/Certificate errors.
Please refer to the following links for more information on Configuring Certificates of PCF:
- https://docs.pivotal.io/pivotalcf/1-8/opsguide/security_config.html
- http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html
- https://docs.oracle.com/javase/6/docs/technotes/guides/net/proxies.html
- http://docs.pivotal.io/pivotalcf/1-9/adminguide/securing-traffic.html
- https://docs.pivotal.io/pivotalcf/1-7/opsguide/custom-load-balancer.html
- https://discuss.pivotal.io/hc/en-us/articles/230613767-How-To-Trust-Public-IP-Ranges-as-Trusted-Proxies-in-Elastic-Runtime
Feedback
