Now let's talk about the different types of certificates used by HDFC.
When you configure HDFC, you need to have at least one certificate already created and that's the SSL
certificate used to secure the web service traffic for communications with clients and Web application
proxy.
It's the same type of certificate you would use in Internet Information Services.
The SSL certificate needs to be trusted by client computers, so it should be signed by a trusted certificate
authority like a public key.
If you're just creating a testing environment, you could use a self signed certificate.
But you'll need that certificate installed on client computers and servers accessing ADF's.
If you're working in a corporate environment, you could also use a certain issued by Active Directory
Certificate Services because the domain joint computers will have the root certificate installed from
the certificate authority.
And that's what we're going to do in the demo environment.
Wild card certificates are supported for the ADF's SSL certificate and it's recommended to use the same
SSL certificate across all nodes of your ADF's form and for the web application proxy servers.
Also, you'll need the private key included in this certificate.
If you want to change the SSL certificate after the ADFA server or farm is set up, you need to do that
through PowerShell.
There are some subject alternative names needed on this certificate.
Also, if you plan to use on premises, device registration or certificate authentication by default,
the SSL certificate is also used as the service communication certificate.
But you can change this after configuration by using the ADF FFS admin interface.
This is actually a server authentication certificate and it's used when setting up a federation between
organisations.
All the ADF, RFS servers in your own farm should use the same service communication certificate.
The recommendation from Microsoft is to use the same certificate here that you used for SSL.
A token signing certificate is required to digitally sign all security tokens that ADF produces and
ADF's creates a self signed x 0.509 certificate with 2048 bit keys by default ADF as also renews the
certificate automatically.
So although you can import your own certificate if your organisation requires it, it's recommended
to just use the default self signed certificate.
The token signing certificate prevents attackers from altering or counterfeiting security tokens issued
by ADF as it's just used to verify that the token hasn't been tampered with.
So the token signing certificate doesn't encrypt the tokens, but there is another self signed certificate
created by ad fs called the token decrypting certificate.
The public key of the token decryption certificate and the public key of the signing cert are both published
in the Federation Metadata XML file that's accessible on a standard web address of your ADF server.
So when you configure in ADF's server in a partner organisation or a relying party application that
uses ADF face, those keys are available to the other ADF's server or the application framework in order
to be able to verify the signature of the tokens as well as for partner organisations to sign the tokens
they issue to your ADF's server.
In a federation scenario, the token decryption certificate is then used on your ADF server to decrypt
the tokens using the private key.
Now let's generate an SSL certificate to use when configuring a DFS in the upcoming demo.