Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

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.

share|improve this question
1  
If you're running Active Directory, you can just create a domain CA and your Windows clients will trust certs it signs. –  jscott Jul 26 '10 at 12:29
    
Nupe. No Windows in this office. Though, I shouldn't be too grateful given your comment detailing how simple it would appear to be. Alas... I appreciate the answer regardless (also for putting up with my lack of detail), and have upvoted it for future readers. –  VxJasonxV Jul 27 '10 at 0:04
    
Also, re-reading this, "I shouldn't be too grateful" was totally not how I meant to say it. When I first typed out the comment, I said "No Windows in this office, thank god." and then took the "thank god" part out, but left the "grateful" comment in, whoops. I hope you didn't take it as "not being grateful for your comment", which is how it sounds, and I thoroughly apologize for that. –  VxJasonxV Jul 28 '10 at 23:47
add comment

4 Answers

up vote 1 down vote accepted

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

share|improve this answer
    
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. –  VxJasonxV Jul 27 '10 at 0:16
add comment

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

share|improve this answer
    
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. –  rmalayter Jul 26 '10 at 13:48
    
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. –  VxJasonxV Jul 27 '10 at 0:13
add comment

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.

share|improve this answer
1  
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? –  VxJasonxV Jul 27 '10 at 0:11
add comment

InstantSSL by Comodo appears to do intranet SSL certificates:

http://www.instantssl.com/ssl-certificate-products/ssl/ssl-certificate-intranetssl.html

By their own description, they are "issued to either a Full Server Name or a Private IP Address." I'd still recommend looking at establishing your own private certificate authority, but you can accomplish what you want.

share|improve this answer
    
Considering they still charge for it (no, I don't blame them for doing so) it certainly would be much smarter for me to roll my own. Thanks for the tip. –  VxJasonxV Apr 24 '11 at 1:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.