I have a friend who wants to publish an MS Certificate Server sitting behind an ISA Server. I personally don't think this will work correctly, due to the actual IP address being different from the publicly available IP address.
Anyone know of a way to make this work....? Dr Shinder.....?
Hi Bruce! I¦m just writing a post reply on the Certificate Server subject as you¦re reading this because I have seen several questions about the Cert Server and I think it needs to be cleared out.
So the solution for your problem right now is: Yes it works! This is what you have to do:
The key forit to work is the DNS... During the installation of the CA Certificate Server (Enterprise root or sub ordinate for example) you choose a common name (FQDN) for the website. This common name (FQDN) is very important to be right. This name (Fully Qualified Domain Name)) has to be able to be resolved against your server from an external client and an internal client.
This means that on you ISA Server you probably have to have a split DNS structure with forwarders with an (A) DNS record for your FQDN domain name (or other solution.) Some DNS machine on the internet have to be able to resolve the external FQDN name to your server as well.
The FQDN¦s who resolves inernally and externally have to be exactly the same as with the commonname on the Certificates, almost ;-) . You are able to use wildcards in the common name (FQDN) when setting up the Certificate Server or when you¦re asking the CA Cert Server for a Certificate (Webserver Certificate as an example).
Oh and one more thing ;-)
When you¦re installing the CA Enterprice Root Server you have to use the CAPolicy.inf file. What¦s this? In this file you can enter some information about the CRL and AIA Distribution Points. You can also enter HTTP links to information about the public policy for the Certificate and a lot more useful information. Search for CAPolicy.inf file on MS.
CRL=Certificate Revocation List AIA=Authority Info Access DP=Distribution Point
This above names links to a .CRL or .CRT file thrue a HTTP,FILE, FTP or LDAP link.
The issued Certificate uses the .CRL file to check if the certificate has been revoced.
The issued Certificate uses the .CRT file to retrieve the Public Root Server certificate.
During the SSL connection to the webserver,the webserver sends the public web server certificate to the connecting client. The client then gets a question if he wants to trust the certificate. If he looks at the certificate (choosing View) he can see the error "The Certificate is not trusted". In order to trust it he must install this web server certificate into the Certificate store. (Open MMC console and choose Certificates Services). If you click install and follow the promts then this is an easy story.
I¦m not sure about if it installs into the "Trusted Root Authoritys" folder or some other folder. Now this public web server certificate is trusted by an CA Root auhtority...you think.
When examining the certificate in the Certificates MMC console you see the following error: "Certificate is not trusted by a Root Certificate Authority" (or similar). If the CRL and AIA links works then when you examine the status of the web server Certificate in the certificate store you see that the Root server Certificate is trusted (it is ok, mean green...)but not the web server certificate (red cross on it).
It is because you need to install the root certificate into the Certificates Store. Normally when you¦re buying a certificate from a public Certificate Authoriy like VeriSign their Root Certificates are already installed into IE, Netscape, Opera etc. But you got a privat CA Certificate Authority (CA Server) so you have to install this Root Certificate into your clients in order to trust issued certificates from this CA Root Enterprise Server Authority.
If the CRL and AIA DP links didn¦t work then the client couldn¦t retrieve the .CRL and .CRT files and this means that he couldn¦t verify if the cert was revoced (.CRL) or not and that the CA Root server authority who issued the webserver cert was OK (.CRT).
Important: The SSL connection to the website is working anyway with or without the error messages. So if you just don¦t bother...
Before you¦re installing the CA Root Enterprise Authority in MS CA Server, config the AIA and CRL links in the capolicy.inf file with LDAP, HTTP, FTP or FILE links reachable for internal and external clients and the FQDN have to be the same.
Config the web publishing rules and Protocol Rules according to this EXCELLENT website articles. I use HTTP both internally and externally but only LDAP internally.
After installation of the CA Server and the Root enterprise certificate you have to examine and configure the AIA and CRL points again. Because if you¦re issuing a web server certificate from the CA Root Enterprise Authority theweb server certificate gets the CRL and AIA default LDAP and HTTP links and they¦re named from the default domainname when you installed the server...
During Windows installation you installed the Server with the host name "host" and the domain name "mydom.local".
Now after installation of MS CA Server with CONFIGURED CApolicy.inf file, CRL and AIA DP is pointing to your real FQDN:
"LDAP://server.domain.com/Certenroll/certname.crl", "HTTP://server.domain.com/Certenroll/certname.crl", "LDAP://server.domain.com/CertEnroll/certname.crt" and "HTTP://server.domain.com/CertEnroll/certname.crt"
The "CertEnroll" name is the default.
If you don¦t configure the AIA and CRL DP BEFORE you issue a web server cert then the CRL and AIA DP on the web server certificate shows up (in the Certificate MMC) with this links:
"LDAP://host.mydom.local/Certenroll/certname.crl", "HTTP://host.mydom.local/Certenroll/certname.crl", "LDAP://host.mydom.local/CertEnroll/certname.crt" and "HTTP://host.mydom.local/CertEnroll/certname.crt"
This works for your internal clients because they¦re able to resolve both FQDN names thrue you internal configured DNS with forwarders but not for your external because they cannot find the local FQDN...
And one more thing...The issued certificates is chained all together all the way down to the Root Certificate so if any CRL or AIA DP link is wrong or missing you get an error on this certificate when you¦re checking it in the MMC Certificates console. "The Certificate couldn¦t be trusted" (or similar).
You want your clients internally and externally to enter "https://server.domain.com" in order to reach the server.
To handle out Machine Certificates automatically on your internal network you just config the GPO policy to issue out Machine Certificates. To handle out User Certificates to you external and internal clients you need to give them access to the default website: "https://server.domain.com/certsrv/" recommended by basic credentials and SSL.
I think this was all and hopefully this have solved your concerns! There can me an misunderstanding somewhere but...who cares ;-)
Maybe Tom (The King) can correct any errors,that would be nice! ;-)