1

I'm building a service in Azure. Rigth now I have 2 servers

  • DC-1
  • Worker-1

Worker-1 does http, ftp and a couple of .exe services that are running around the clock. Both DC and Worker are part of a .com domain I've set up.

I needed to secure some HTTPS service on Worker-1 so I've got a "domain verified" SSL certificate. I now need to secure that FTP service that is running too...

1) Can I use the same certificate or do I have to get another "domain verified" for the ftp.foo.com (ftp)?

2) Getting a wildcard SSL certificate solves the problem above, where I can secure both (and more) ftps://asd1.foo.com and https://foo.com?

Please look at 1) as two simple certificates are cheaper than a wildcard so for now it might be the best economical solution.

3) What if I moved the FTPS service to another server? If I create Worker-2 and set up FTPS service on that. Can I still utilize the same certificate? Guessing I at least need a wildcard here as I still have the https running on Worker-1.

Or do I in this case need a "Organization Verified" certificate? I understand there are three types, DV, OV and EV certificates. Could I in 3) simply add the certificates to the Active Directory and everything magically runs? :) Wishful thinking, I'm not sure how certificates work a cross servers in a domain.

fUrious
  • 11
  • 1
  • 3

1 Answers1

1

Technically, there’s not much difference between DV, OV and EV. They’re all just SSL certificates assigned to a certain subject name - or group of names.

There’s nothing wrong with using one certificate on multiple servers, as long as the certificate covers the subject names you are using. If your existing certificate doesn’t list ftp.domain.com, then you can’t use it for that hostname.

The simplest option if you already have a cert for domain.com is to just get another one for ftp.domain.com.

You can also get a “SAN” certificate that covers multiple names. The certificate has a list of alternative names, ftp.domain.com, mail.domain.com, etc. The provider I use sell certificates that cover up to 5 names for not much more than a single one. (The name SAN comes from the field that holds these names inside the certificate - “Subject Alternative Names”. You can view these in the properties of the certificate)

A wildcard certificate should also work - although make sure it actually covers “domain.com” and not just “something.domain.com”. This is probably more expensive that a SAN certificate, but gives you freedom to set up someservice.domain.com in the future and use the existing certificate.

USD Matt
  • 5,381
  • 15
  • 23
  • Thank you Matt. I cant upvote you because of my low reputation. – fUrious Nov 15 '17 at 07:34
  • However, if you have one certificate across multiple servers and one of your servers is compromised (and therefore your private key isn't private any more), then that certificate is compromised on all servers. Sharing works technically, but might not be the most secure. It depends on your appetite for risk (and maybe your security policy?) – garethTheRed Nov 15 '17 at 08:13