Certificate Management via AD
From Extension Collaborative Wiki
Security Certificates are used to encrypt network traffic for SSL encrypted connections. Examples include HTTPS, IMAPS, and LDAPS. The "S" denotes a secure/encrypted connection. No confidential data (esp usernames/passwords) should ever be sent over a non-secure connection.
It is possible to sign your own certificates, but that makes a warning pop up when you connect saying that the site could not be verified as trusted. The simplest free solution is to trust a single server and let it sign all certs. Trusting the certificate issued by that server eliminates the warning for all other server certificates in the hierarchy of trust. If you are managing your machines with something like Active Directory you can transparently (to the user) push that root certificate to all managed machines and never see the warning (because it will be trusted just like CertaSign, SecureSign, VeriSign, and the other trusted authorities).
Trusting the certificates self-signed by eXtension
- Download a local copy of the eXtension Root Certificate from the eXtension Certificates section on importing the root certificate authority.
- Change the file extension on that file from .pem to .cer
- Open Group Policy Management Console and edit the appropriate Group Policy
- In \Computer Configuration\Windows Settings\Public Key Policies
- Right-click Trusted Root Certification Authorities and select "Import"
- use the Certificate Import Wizard to place the certificate in the Trusted Root Certification Authorities certificate store.
- In \Computer Configuration\Windows Settings\Public Key Policies
Signing your own certificates
Choose a Windows2003 Server to be your root certificate authority. Use Add/Remove Programs to add the Windows Component called "Certificate Services". Use it to sign all the certificates for your other server certificates. The windows interface is almost intuitive for requesting and issuing certificates once you've figured out the concept.
