Here is the question:
I have been trying to understand the certificate requirements in ITI-TF 2, 126.96.36.199 (Other Certificate Requirements) especially:
"The Secure Node shall not require any specific certificate attribute contents, nor shall it reject certificates that contain unknown attributes or other parameters. Note that for node certificates the CN often is a host name, attempting to use this host name provides no additional security and will introduce a new failure mode (e.g., DNS failure). "
This requirement appears vague to me in that though it talks about CN not providing any additional security, it does not state whether we are supposed to consider it during validation or not.
I understand that may be it is up to the implementer, what I would really like to know is whether rejecting a certificate due to host name mismatch ( for e.g My repository is NOT using a certificate with Common Name = machine name/host name) should reject requests from a Client who is using my repository's endpoint (where Common Name is NOT = machine name/host name).
I would like to know how others are dealing with certificate validation and specifically Common Name mismatch errors.
1. What does "shall not require any specific certificate attribute contents, nor shall it reject certificates that contain unknown attributes or other parameters" mean?
- If as a Secure Node, I want to only allow certificates know to me and reject the rest, is that counted as not meeting IHE spec?
2. Are we supposed to ignore Common name mismatch errors entirely? And are they supposed to be ignored on the Client side (If I am a Document Source sending a document to a repository) or on the Server side (I am a registry accepting a query from a Document Consumer)?
I will really appreciate any more information on this.
- Don't disassemble ATNA, what you are looking for is there.
- Why Mutual-Authorized-TLS?
- Testing ATNA Secure Communications
- Direct addresses- Trusted vs Trustable
- Identity - - Proofing
- Securing RESTful services
- IHE Encryption choices
- Healthcare use of X.509 and PKI is trust worthy when managed
- SSL is not broken, Browser based PKI is
- Meaningful Use Stage 2 :: SHA-1 vs SHA-2
- Trusting e-Mail
- S/MIME vs TLS -- Two great solutions for different architectures
- Healthcare Provider Discoverability and building Trust
- Using both Document Encryption and Document Signature
- Document Encryption
- IHE - Privacy and Security Profiles - Document Encryption