creating PKI certificates without using a FQDN in the Name field

[Guest Good2go]

Hi all;

I'm hoping someone can shed some enlightenment. I'm configuring SCOM for a

customer and we're trying to monitor machines in a DMZ that are not part of a

domain. In fact although they are in workgroups, there are no workgroup

servers. The servers and PCs that are needing monitoring are all standalone.

 

We've stood up a standalone root CA, and created certificates for the SCOM

servers, imported them to both the Local Computer store and used

MOMCertImport.exe to use them with SCOM. However, all the documentation I've

seen so far says that to create the certificate for the non-domain machines,

the cert requires a FQDN. How can you use and FQDN for a machine that is not

a member of a domain?

 

We created a certificate with just the computer name in the Name field, but

seem to have no joy here. To forestall responses about using a Gateway

server, the customer is adamantly opposed to this. (No $$ for the hardware)

 

So, can anyone help out? (I posted this in the Ops Manager forum as well).

TIA!

[Guest Alun Jones]

"Good2go" <Good2go@discussions.microsoft.com> wrote in message

news:80F55088-2776-4738-BB1B-D90C69A80887@microsoft.com...<span style="color:blue">

> I'm hoping someone can shed some enlightenment. I'm configuring SCOM for a

> customer and we're trying to monitor machines in a DMZ that are not part

> of a

> domain. In fact although they are in workgroups, there are no workgroup

> servers. The servers and PCs that are needing monitoring are all

> standalone.

>

> We've stood up a standalone root CA, and created certificates for the SCOM

> servers, imported them to both the Local Computer store and used

> MOMCertImport.exe to use them with SCOM. However, all the documentation

> I've

> seen so far says that to create the certificate for the non-domain

> machines,

> the cert requires a FQDN. How can you use and FQDN for a machine that is

> not

> a member of a domain?</span>

 

The "domain" in "Fully-Qualified Domain Name" is a different concept from

that of the "domain" as in "my computers are workgroup computers, not domain

members".

 

A "Fully-Qualified Domain Name" indicates the name that a system can be

referred to using the DNS (Domain Name System) services - the "Internet

Name", if you like. It's "fully qualified", because it's a name that can be

resolved from the 'root' of the system, rather than being relative to some

current location.

 

For instance, let's say I work at "example.com", and you work at

"nothere.invalid". If I try to connect to the site "www", I will connect to

"www.example.com", and if you try to connect to the site "www", you will

connect to "www.nothere.invalid". Those are examples of the relative name

"www" being expanded into the FQDNs "www.example.com" or

"www.nothere.invalid".

<span style="color:blue">

> We created a certificate with just the computer name in the Name field,

> but

> seem to have no joy here. To forestall responses about using a Gateway

> server, the customer is adamantly opposed to this. (No $$ for the

> hardware)</span>

 

Now, the "CN" or "Common Name" in the certificate for a server has a simple

rule - it _must_ match the name that was provided by the user to the client

software. So, if the user entered "https://www.example.com" in the browser

as a URL to connect to, the browser will complain, and possibly prevent

connection to the site unless the site gives back a certificate whose CN

value is "www.example.com". If the CN in the certificate is

"www.example.com", and the user enters "https://www" into the browser, then

even though this is expanded by the DNS resolver into "www.example.com", the

browser will reject the certificate as being the wrong name.

 

The converse is true - if you provide a certificate with "www" as the CN

value for its Subject field, the browser will complain if it reached the

server using "https://www.example.com" in the address field, but will behave

happily if the user entered "https://www" to reach the server.

 

Why does every document out there tell you to use FQDNs? This is because

then the certificate created for your site cannot be used to represent

someone else's site. The recognised Root CAs should refuse to sign

Certificate Signing Requests unless they contain an FQDN. Sadly, at least

one does, because I have seen it happen.

 

The question of "what name should go in my Subject field?" is answered by

asking the question "what name is supplied to the browser (or other client)

when a connection is requested?"

<span style="color:blue">

> So, can anyone help out? (I posted this in the Ops Manager forum as well).</span>

 

Please don't post to multiple newsgroups like that - use cross-posting, so

that you post _one_ copy of the message, and it is seen in both newsgroups.

If you can't find a way to do that in whatever newsreader you are using (if

you are brought here by any of a number of web interfaces, you may have been

told that this is a "forum"), then simply don't post to multiple newsgroups,

and find a newsreader that will let you cross-post.

 

Alun.

~~~~

--

Texas Imperial Software | Web: http://www.wftpd.com/

23921 57th Ave SE | Blog: http://msmvps.com/alunj/

Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.

Fax/Voice +1(206)428-1991 | Try our NEW client software, WFTPD Explorer.