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

  • 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 '14 at 13:48
  • @paul Can you clarify your question as to what you're asking here? – dan May 25 '14 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 '14 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 '14 at 0:53

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 | |
  • 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 '14 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 '14 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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