Re: creating PKI certificates without using a FQDN in the Name field

"Good2go" <Good2go@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:80F55088-2776-4738-BB1B-D90C69A80887@xxxxxxxxxxxxxxxx
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?

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".

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)

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?"

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

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.



.

Relevant Pages

  • Re: Keeping Communication open between DMZ and Network
    ... preshared key or certificate for machine authentication with certificate being the ... Policy to manage the policy but you can export/import to other W2K machines. ... > I am looking for a solution to keep 2000 Servers in a DMZ ...
    (microsoft.public.win2000.security)
  • RE: SSL Reverse Proxy
    ... You can install the certificate on both servers. ... We already know the security implications of this approach. ...
    (Security-Basics)
  • RE: Server Certificates
    ... servers it woked fine until I promoted the one server to a domain controller. ... certificate infrastructure just to RDP. ... about Certs with RDP unless you are building custom .rdp files for the ...
    (microsoft.public.windows.server.active_directory)
  • Re: SSL with SharePoint on DMZ
    ... > internal and external access. ... > For internal access the certificate has the wrong FQDN ... > Has anyone ever set up a second virtual site pointing to ...
    (microsoft.public.sharepoint.portalserver)
  • Re: OWA Issues After Changing IP Address
    ... Did you try to rerun CEICW and made sure the web certificate is the same as ... your public IP or FQDN (if your ISP has created a DNS record for that FQDN)? ... Contact the server administrator. ...
    (microsoft.public.windows.server.sbs)
Loading