Offline Root CA
If you are using a 2008 AD and upward Active Directory, you will be able to Edit the Default Domain policy and add the CAroot Cert and CA Intermediate Cert in to the policy. This is ofcourse after you have installed the servers and have those certificates to import. This GPO import will allow your Machines on the Domain to automatically add the certs to their store. Rather than having to push them out manually. But take note that if you use a 2003 AD, you will need to create a script to deply the intermediate cert, as the GPO option for intermediate certificates is not available in 2003 AD.
First of all, do not install a CA on a Domain Controller! You want to create two new VMs and have one attached to the domain and the other not on the domain. See below:
If you are using a 2008 AD and upward Active Directory, you will be able to Edit the Default Domain policy and add the CAroot Cert and CA Intermediate Cert in to the policy. This is ofcourse after you have installed the servers and have those certificates to import. This GPO import will allow your Machines on the Domain to automatically add the certs to their store. Rather than having to push them out manually. But take note that if you use a 2003 AD, you will need to create a script to deply the intermediate cert, as the GPO option for intermediate certificates is not available in 2003 AD.
First of all, do not install a CA on a Domain Controller! You want to create two new VMs and have one attached to the domain and the other not on the domain. See below:
- Connect subordinate server to domain
- Install AD certificates sevices on stand alone Root server
- Only install the certificate authority
- Click Configure AD certificate services
- User the local admin credentials (as this is not on domain)
- Setup "Standalone CA"
- Make it the Root CA
- Create a new Key Pair
- Select RSA Microsoft Software Ket Storage Provider 2048
- SHA2 for the cert fingerprint
- Keep the Common Name
- Validity Period 10 years (Only have to turn this on every 10 years)
- Default DB locations
- configure
- Go into Cert Authority Snapin
- Right click your server name in Cert authority snapin, properties
- CDC -
- AIA - Where you pull your public key from. You need to configure this
- so that when unit is turend of the public key can be taken form server 1
- Once you get the public key, it isn't valid until the Certificate Revokation list is checked (CRL)
- In Extensions Tab, Select Extension "CRL Distribution Point (CDP)
- Select "C:\windowssystem32...."
- Publish CRLS to this location and Publish Delta CRLs to this location are checked
- Click on LDAP and check include all crls specify where to publish in the active directoy when publishing manually
- Go to HTTP and remove it
- Go to File and remove it
- Add, custom location. http://subserver/certenroll/<caname><CRLNameSuffix><DeltaCRLAllowed>.crl
- click OK
- Include CRLS & INCLUDE CDP extension certificates
- For AIA - Remove HTTP and File
- Tick Include the AIA extension of issued certificate
- Add custom Location: http://subserver/certenroll/<ServerDNSName>_<CaName><CertificateName>.crt
- Click OK
- Make sure that Include in the AIA extension of issues certificates
- Restart
- Go to Revoke Certificates, right click All Tasks, Publish, New CRL
- CMD - to command line
- certutil -setreg CA\validityperiod "years"
- certutil -setreg CA\validityperiodunits 10
- certutil -setreg CA\DSConfigDN "CN=Configuration,dc=yourdn,dc=yourdn"
- certutil -setreg CA\DSDomainDM "dc=yourdn,dc=yourdn"
- Right click server in CA auth mmc and restarts services
- Go to revoke certificate, properties, publish
Subordinate server
- Install AD certificates
- Add CA authority and Certificaew web service
- Next and install
- Configure tick Certificate authority
- Select Enterprise CA
- Select Subordinate CA
- Create Key pair
- RSA 2048
- Keep the server common name
- SAve the certifiacte to c: drive
- next
- configure
- You will get warning, but thats normal
- Open Explorer
- Show hidden files
- C:\
- You will see the CSR .req file
- open new explorer window and go to stand alone server c$ on root server
- windows\system32\certsrv\certenroll
- Copy .req file from sub server to certenroll server on root
- Go to C:\windows\system32\certsrv\certenroll on sub server c:
- copy both files from cert enroll on root server to sub cert enroll server. not req
- Got to Rootserver
- Right click server, all tasks, submit a new request.
- C:\windows\system32\certsrv\certenroll and select .req
- will show in pending requests, hit F5
- Right click on the the pendign request and select Issue
- It will appear in issued certificates
- double click it
- Detail
- Copy file
- Choos PKCS7 include all certs in cert path
- next
- Save as subserver. So this has exported the private key
- Goto sub server
- CMD prompt
- certutil -dspublish -f server2_server2-ca.crt RootCA
- certutil -dspublish -f server2-ca.crl
- certutil -setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE
- Open MMC cert services
- Right click Root CA
- All tasks
- install CA
- goto cert enroll dir on sub server
- choose p7b file
- OK
- Shutdown Root Ca
- Goto sub server
- MMC - riclick and start service
- gpudpate / force
- will autoenroll
- Domain controller will grab a cert
- GPMC
- Domain Defualt Policy
- Policies
- Windows settings
- Security settings
- Public Key policies
- Intermidate cert authorities
- R click import
- Got to Enroll folder and select "server1.crt"
- Goto Trusted root and import root.crt from Enroll folder
http://msitproblog.com/2015/10/27/installing-an-app-v-5-1-server-infrastructure/
If you wish to configure your XenApp environment to be accessible via the same URL, both internal or external, then be aware that this isn't as simple as it used to be with Web interface. Web interface was in no way comparable to the enhanced security and architecture of the modern Citrix Storefront and Netscaler Access Gateway.
To configure the same URL for both internal and external users, you will likely need a SAN certificate with the CN name configured for your external domain, plus the internal Load Balanced store DNS address and Callback address.
It is possible to configure the Receiver client to use Beacons and identify whether they should authenticate via an internal or external URL. Think carefully with regards to single URL, as it may not be required. I'm not a fan of placing the internal storefront name on a Public Certificate. Do your users really care whether they have to type in "Storefront" into their web browser when working on site? It is also very easy to just place the external url on a corporate internet page as a link, or add the link as a shortcut to the Desktop or Browser favourites. Do you really need a single URL? Probably not.
To configure the same URL for both internal and external users, you will likely need a SAN certificate with the CN name configured for your external domain, plus the internal Load Balanced store DNS address and Callback address.
It is possible to configure the Receiver client to use Beacons and identify whether they should authenticate via an internal or external URL. Think carefully with regards to single URL, as it may not be required. I'm not a fan of placing the internal storefront name on a Public Certificate. Do your users really care whether they have to type in "Storefront" into their web browser when working on site? It is also very easy to just place the external url on a corporate internet page as a link, or add the link as a shortcut to the Desktop or Browser favourites. Do you really need a single URL? Probably not.
