So I've recently moved from WHS V1 to 2011 - just as that's going to 2012 I know- but there we are....
Like many others I find the rather limited options of the remote setup and the hidden nature of the configuration and operation of the complex web .net front end a pain.
I have the following discoveries to share though which might help others.
As far as your own certificate goes for remote access the following inf file is all you need.
=======
[Version]
Signature= "$Windows NT$"
[Strings]
szOID_SUBJECT_ALT_NAME2 = "2.5.29.17"
szOID_ENHANCED_KEY_USAGE = "2.5.29.37"
szOID_PKIX_KP_SERVER_AUTH = "1.3.6.1.5.5.7.3.1"
szOID_PKIX_KP_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2"
[NewRequest]
Subject = "CN=my fully qallified domain name"
FriendlyName = Server Certificate
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[Extensions]
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%"
=====
you just need to modify the fully qualified domain name and save it to an .inf file.
then do
certreq -new inf_file.inf request.req
(There are other posts on here that will tell you how to modify the CA extension list to add external CRL and AIA points to the CA.)
Then right click the CA and submit a new request.
Click the pending folder and issue the pending cert.
Then go into issued certs – export the highest number request to a “binary data” “file” and call it new.cer (not Binary out.tmp – or whatever the server calls it).
Then VERY IMPORTANT – do:
Certreq –accept new.cer This joins the private key (which was sitting in the CAPI store protected with DPAPI) to the public key which is now signed.
Obviously if you try to run the command above in a different profile or machine from where you ran certreq –new there will be no waiting private key so it will fail.
Anyway – now you have a new cert with the name you want on it.
The server may still be whinging about the lack of remote connectivity – so I suggest you go ahead and request a cert using your windows live id.
Once you have done that and it’s working…
You need to add the certhash of the cert you requested above to the following registry location.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Server\RDP GatewayCertHash
Then restart tsgateway.
Then deleted the existing ssl cert
Netsh http delete ipport=0.0.0.0:443
Add the new one:
netsh http add sslcert ipport=0.0.0.0:443 certhash=my new cert hash appid={4dc3e181-e14b-4a21-b022-59fc669b0914} clientcertnegotiation=disable usagecheck=enable verifyclientcertrevocation=enable certstorename=MY
issue an issreset
Once you have done this. You will have no problems with any existing applications or connectivity to the server as is not the case with other methods.
The only issue is that when you click “Remote Web Access” from a client it will try to connect to the FQDN of the cert you requested using Windows Live ID and not the one that you have now assigned.
This is because when you assign the windows live ID one the wizard I am guessing – updates the clients with the new URL and I have yet to determine how this is done.
If anyone knows where on the client the launchpad “Remote Web Access” URL is stored – (an extensive procmon session has not revealed where yet) Id be very glad to know!
Like many others I find the rather limited options of the remote setup and the hidden nature of the configuration and operation of the complex web .net front end a pain.
I have the following discoveries to share though which might help others.
As far as your own certificate goes for remote access the following inf file is all you need.
=======
[Version]
Signature= "$Windows NT$"
[Strings]
szOID_SUBJECT_ALT_NAME2 = "2.5.29.17"
szOID_ENHANCED_KEY_USAGE = "2.5.29.37"
szOID_PKIX_KP_SERVER_AUTH = "1.3.6.1.5.5.7.3.1"
szOID_PKIX_KP_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2"
[NewRequest]
Subject = "CN=my fully qallified domain name"
FriendlyName = Server Certificate
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[Extensions]
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%"
=====
you just need to modify the fully qualified domain name and save it to an .inf file.
then do
certreq -new inf_file.inf request.req
(There are other posts on here that will tell you how to modify the CA extension list to add external CRL and AIA points to the CA.)
Then right click the CA and submit a new request.
Click the pending folder and issue the pending cert.
Then go into issued certs – export the highest number request to a “binary data” “file” and call it new.cer (not Binary out.tmp – or whatever the server calls it).
Then VERY IMPORTANT – do:
Certreq –accept new.cer This joins the private key (which was sitting in the CAPI store protected with DPAPI) to the public key which is now signed.
Obviously if you try to run the command above in a different profile or machine from where you ran certreq –new there will be no waiting private key so it will fail.
Anyway – now you have a new cert with the name you want on it.
The server may still be whinging about the lack of remote connectivity – so I suggest you go ahead and request a cert using your windows live id.
Once you have done that and it’s working…
You need to add the certhash of the cert you requested above to the following registry location.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Server\RDP GatewayCertHash
Then restart tsgateway.
Then deleted the existing ssl cert
Netsh http delete ipport=0.0.0.0:443
Add the new one:
netsh http add sslcert ipport=0.0.0.0:443 certhash=my new cert hash appid={4dc3e181-e14b-4a21-b022-59fc669b0914} clientcertnegotiation=disable usagecheck=enable verifyclientcertrevocation=enable certstorename=MY
issue an issreset
Once you have done this. You will have no problems with any existing applications or connectivity to the server as is not the case with other methods.
The only issue is that when you click “Remote Web Access” from a client it will try to connect to the FQDN of the cert you requested using Windows Live ID and not the one that you have now assigned.
This is because when you assign the windows live ID one the wizard I am guessing – updates the clients with the new URL and I have yet to determine how this is done.
If anyone knows where on the client the launchpad “Remote Web Access” URL is stored – (an extensive procmon session has not revealed where yet) Id be very glad to know!