Will Any Popular Root CA Sign a host.domain.local Certificate?

My boss refuses to allow private IP addresses into a public DNS definition. So I am unable to put the private SVN box IP (svn.ourcompany.com) into a .com DNS record. It exists only at svn.ourcompany.local

I don't mind this, ultimately, except when it comes to SSL. Oh SSL... I think I may see TLS in my future, pending software support.

... uhh, at any rate.

Is there a popular (root CA cert pre-installed in all OSes) CA that signs .local certificate requests? It doesn't need to have any bells and whistles, no wild card, it can even cost a nominal fee.

I really don't want to go around and install a self-rolled root CA in every user's computer, and have to redo it when something changes. It's just annoying.

From serverfault VxJasonxV

• Why not use a local DNS server that doesn't answer external requests, with an entry for your SVN server? Or does that violate the "public DNS definition" policy (which is absurd, if the host is not publicly resolvable)?

  VxJasonxV : After reading through all of these responses, this seems like the answer. To have an 'ourdomain.com' zone that exists on a DNS server for all of our users internally, and a forwarder to our public one perhaps, maintained separately from one another. The reason why we moved to .local is because we previously used a .net address that actually existed in the world, and had a few high profile concerns about misconfigured clients sending data to some squatter on the public net.
  From Andrew

• Your boss is smarter than you possibly think. Mapping a local address on a public DNS server does not make much sense.

  You should better configure an internal DNS server (Bind works like a charm on a minimal Linux installation, or you can use the DNS facility of an AD domain controller if you're on Windows) and define a delegation zone for addresses hosted within your domain.

  Speaking of SSL/TLS certificates, you can easily create and manage your own ones with the openssl command. If you feel more comfortable with a gui and you're working under Linux you can install a tool called TinyCA2.

  A self-generated certificate is as good as a paid one in terms of cryptographic security, you could just receive some harmless alert from the svn client (or web browser) while connecting for the first time because the emitting authority (yourself) is not recognized as certified.

  M

  rmalayter : You don't need AD running to use Windows DNS... it functions just fine as a primary or secondary DNS zone host using files for databases instead of the AD database.

  VxJasonxV : The point is to not have the nag screens ala. Firefox 3+ with regard to "invalid" (self-signed) certificates. I know the security is just as good, but really it's just a pain in the neck. And the answer isn't "accept once and never again" either, anyone who says that is a fool. I have multiple browsers, different svn clients, svn deployment processes (independent process), and users to support, all of which have to have their SVN stores in perfect sync less I be bombarded with grunt tasks of synchronization across all systems.
  From MariusPontmercy

• Firstly: the answer to the question as such has to be "no", simply because the .local TLD is not a public TLD and therefore clients would unable to trace this back to a root certificate.

  However, as the others have pointed out, you can run a local DNS server. In fact, in our case we run internal DNS and external DNS on the same domain, but providing different results, depending on where the query comes from. And as soon as you run your internal network on a .com TLD, you can use certificates issued by any root CA.

  VxJasonxV : It may be my lack of knowledge in the process, but why does any TLD, in existence or not, affect how a client "traces back" to the root CA? If a certificate says "VeriSign Signing Authority" signed it, which matches a CA Cert stored in the user's chain, what does the client have to "trace back" except to the CA/CA's CRL?
  From wolfgangsz