rwickersham
asked on
This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store.
I installed Certificate Server & configured it per http://www.msexchange.org/tutorials/SSL_Enabling_OWA_2003.html
My intent is to issue SSL certificate for OWA and not get a "Certificate Error" in IE7.
When I access the web/OWA/Exchange server from a machine across the Internet, I receive the "Certificate Error"., When I view the certificate, i find "This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store."
I believe the certificate server was to resolve this.
Where to go from here?
My intent is to issue SSL certificate for OWA and not get a "Certificate Error" in IE7.
When I access the web/OWA/Exchange server from a machine across the Internet, I receive the "Certificate Error"., When I view the certificate, i find "This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store."
I believe the certificate server was to resolve this.
Where to go from here?
What mike said is essentially correct.
The only difference between a "commercial" (paid for) certificate and one you make yourself is that all browsers have the CA "root" certificate in their root stores by default, but yours is freshly minted and not in anyone's store.
However, you can push out new certificates to machines you control in several manners - if nothing else, they are just registry keys, and can be exported/imported as such. You can also push out new root certs via group policy (and in fact, can *issue* client side certificates in a similar manner, allowing you to use them for email security and client authentication) or, failing that, just email the root .cer file to all your users and tell them to double-click it.
The only difference between a "commercial" (paid for) certificate and one you make yourself is that all browsers have the CA "root" certificate in their root stores by default, but yours is freshly minted and not in anyone's store.
However, you can push out new certificates to machines you control in several manners - if nothing else, they are just registry keys, and can be exported/imported as such. You can also push out new root certs via group policy (and in fact, can *issue* client side certificates in a similar manner, allowing you to use them for email security and client authentication) or, failing that, just email the root .cer file to all your users and tell them to double-click it.
ASKER
I was confused on multiple items. I understood, apparently mistakenly, from http://www.msexchange.org/tutorials/SSL_Enabling_OWA_2003.html, that manual importation of the certificate in the "trusted root store" was no longer necessary. When I did add the certificate to the "trusted root store" I still received the error. I failed to close & re-launch the browser.... Stoopid me!
Obviously, a GP push won't happen over the internet.
Lastly, I am gathering the certificate server merely generates self-signed certificates. I have generated these over the years using OpenSSL. How is the certificate server any different? What additional functionality does the certificate server perform?
Obviously, a GP push won't happen over the internet.
Lastly, I am gathering the certificate server merely generates self-signed certificates. I have generated these over the years using OpenSSL. How is the certificate server any different? What additional functionality does the certificate server perform?
That link is incomplete (or I'm missing where they mention this) - they should have instructed you to install the root cert on the server and the client.
You can make the root cert available on a public link - you will also need to have at least one of your CRL Distribution Points (CDP) and Authority Information Access (AIA) locations be publicly accessible - usually easiest to use a scheduled task on the CA to run a script prior to CRL expiration, then copy it to the public location. Can script a CRL publish with: certsrv -crl
In your OWA documentation just include the instructions on how to import your root cert including the download URL. You can always rename the .crt file to make it easier, e.g. http://www.domain.com/pki/CompanyRoot.crt
Alternatively, you can get a commercial cert for about 30 bucks from GoDaddy and it will be part of the cert store already for your users. If you plan to go for ex2007 then you may want to look into getting a UC cert instead for about 70 bucks.
You can make the root cert available on a public link - you will also need to have at least one of your CRL Distribution Points (CDP) and Authority Information Access (AIA) locations be publicly accessible - usually easiest to use a scheduled task on the CA to run a script prior to CRL expiration, then copy it to the public location. Can script a CRL publish with: certsrv -crl
In your OWA documentation just include the instructions on how to import your root cert including the download URL. You can always rename the .crt file to make it easier, e.g. http://www.domain.com/pki/CompanyRoot.crt
Alternatively, you can get a commercial cert for about 30 bucks from GoDaddy and it will be part of the cert store already for your users. If you plan to go for ex2007 then you may want to look into getting a UC cert instead for about 70 bucks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
oh, and the ms CA generates two level certificates - it has a self signed (CA) issuing certificate, which it uses to sign actual end-node certificates (so web server or user)
Anything else we can help you with, or are you all set?
YOu will have to do this on each and every client, the only way around it is to use a public cert.