If your company has an enterprise CA, you
can use that to issue your certificate, provided that it is co-signed by a root CA that participates
in Microsoft??™s Root Certificate Members Program. If you don??™t have an existing
certificate, you have two options: You can purchase one or you can create and import a
self-signed certificate. The only problem with using a self-signed certificate is that clients
will receive warnings that the certificate comes from an untrusted source whenever they
try to connect unless the clients have your self-generated root certificate imported into
their trusted root certificate stores. Since we??™re setting up only a test environment here,
we can use a self-signed certificate and simply ignore the warnings.
The certificate must also comply with additional certificate requirements:
?–? The name in the Subject line must match the name configured in the TS
Gateway server.
?– The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.7.3.1).
?– It must have an associated private key.
?– It cannot be expired.
?–? If you configure TS Gateway with NAP support, it must also support
encryption. The object identifier (OID) for this type is 2.5.29.15.
Creating a Self-Signed Certificate (Required if
You Don??™t Have a Certificate)
If you don??™t have a certificate you can generate or use and don??™t want to purchase one
for the purpose of testing, your only option is to create a self-signed certificate.
Pages:
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346