...
- A CN or subjectAltName matching the intended hostname(s)
Optional or Required? - Either omission of the TLS Client and Server Authentication extensions, or inclusion of the Server Authentication extension.
In the case of certificates used for SSL client authentication:
- Either omission of the TLS Client and Server Authentication extensions, or inclusion of the Client Authentication extension.
Required. Your server names have to be correct. To increase your chances to work with other products, here is some more advice. Fine to have suggestions. Best practices to maximize the chances that things will work.
The SSL requirements MAY be left to the discretion and responsibility of federation participants; InCommon merely highlights the requirements that are likely to cause problems if not met.
...
Third-party certificates signed by an authoritative CA are discouraged since they can create interoperability issues in certain cases, and lead to configurations that mistakenly rely on the certificate signer to establish trust in the certificate. Where necessary they can be accommodated because of constraints imposed on participants from other sources.
"If web servers and SSL could deal with bare keys, we'd be fine."
Disclaimers
| Wiki Markup |
|---|
\[SC: No, we shouldn't check any certificate content other than what's listed above or can be used to identify cryptographic flaws (e.g. weak keys)\] (!) |
- Disclaimer in the metadata itself
- Disclaimer check box upon submission: Talk to Legal.
Do we need an additional FAQ or is this sufficient?