For example, if two organizations, Alpha and Beta, need to communicate, Alpha's server Hub-A obtains a certificate from Beta and turns off the "Trust" option. Hub-A now has a trusted Alpha certificate and an untrusted Beta certificate. Beta's server Mail-B obtains a certificate from Alpha and turns off the "Trust" option. Mail-B now has a trusted Beta certificate and an untrusted Alpha certificate.
Hub-A presents Beta's certificate to Mail-B because Mail-B trusts that certificate. Mail-B present Alpha's certificate to Hub-A because Hub-A trusts that certificate. Authentication proceeds because the servers have certificates from the same certifiers even though they don't share a trusted certificate.
Optionally, "trust" could be turned on for Beta's certificate on Hub-A, and Hub-A would accept any ID containing a Beta certificate. By doing this, other servers at Alpha do not need to get any new certificates. However, servers at Alpha would be vulnerable to access by fraudulent IDs created by Beta.
Unlike cross-certification used between hierarchical organizations, certifying between flat organizations requires that server IDs be certified individually.
To exchange flat certificates between organizations, each organization should follow the steps described in the topics Recertifying flat IDs using Notes mail or Recertifying flat IDs without Notes mail.
Each organization should make sure to turn off the "Trust other certificates" option for the certificate received from the other organization.
Note Hierarchical organizations that want to certify server IDs of flat organizations must create a flat certifier ID with which to do this.
For more information about creating a flat certifier ID, see the topic Creating a flat certifier ID.