2

(I'm fairly sure I know the answer, but just in case...)

We want SSL on an internal-use webserver, but the usual ones don't work for the usual reasons (not static IP, subdomain issues etc.).

Server identity is not an issue, all we need is an encrypted connection for the slightly-sensitive data. Management's main worry is wifi-sniffing at a cafe. MITM attacks are not a concern (the data involved isn't worth the effort) but the Big Red Warning Page is an issue - the users are just not capable of understanding the issue and adding an exception. This means no self-signed certificates.

Improve this question
4
  • Who is the SSL Website being served to? Staff or Customers? If staff see answer, if customers let me know :P
    – Simon Hayter
    May 24, 2014 at 13:48
  • @paul Can you clarify your question as to what you're asking here?
    – dan ♦
    May 25, 2014 at 1:06
  • Ummm ..... what part is unclear? SSL certs normally verify the server's identity and add encryption to the connection. We want one that only adds encryption and never causes a browser warning.
    – paul
    May 25, 2014 at 8:56
  • 1
    AFAIK "verifying the server's identity" is a vital part of the SSL handshake in order to prevent MITM attacks (as you mention). If you want to skip the "identification" part then I don't think you can use SSL, period. But what else can you (easily) use? This question on the crypto stack site discusses some possibilities: crypto.stackexchange.com/questions/1150/…
    – MrWhite
    May 26, 2014 at 0:53

1 Answer 1

Reset to default
1

You should never need to tell a user to do this and that... Network administration has become almost automated over the last decade. You can push a SSL certification to all machines using Group Policy's.

To distribute certificates to client computers using Group Policy

  1. On a domain controller in the forest of the account partner organization, click Start, point to Administrative Tools, and then click Group Policy Management.
  2. Find an existing Group Policy object (GPO) or create a new GPO to contain the certificate settings. Ensure that the GPO is associated with the domain, site, or organizational unit (OU) where the appropriate user and computer accounts reside.
  3. Right-click the GPO, and then click Edit.
  4. In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies, right-click Trusted Root Certification Authorities, and then click Import.
  5. On the Welcome to the Certificate Import Wizard page, click Next.
  6. On the File to Import page, type the path to the appropriate certificate files (for example, \adfsresource\c$\adfsresource.cer), and then click Next.
  7. On the Certificate Store page, click Place all certificates in the following store, and then click Next.
  8. On the Completing the Certificate Import Wizard page, verify that the information you provided is accurate, and then click Finish.
  9. Repeat steps 2 through 6 to add additional certificates for each of the AD FS servers
Improve this answer
2
  • You make a large, and false, assumption. Microsoft products are banned in my realm. (and I didn't ask for a how-to, just if it's possible and if yes, what's it called)
    – paul
    May 24, 2014 at 15:34
  • 2
    Your assumption that only AD support is possible in Microsoft Products is false. The answer given is a valid one for those using Windows Server but the method can be adopted across a range of operating systems. Since you have failed to mention the setup you’re using you should expect some answers to be board. You should also expect some answers to help others while not so helpful for yourself. We do not promote yes/no questions or answers.
    – Simon Hayter
    May 25, 2014 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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