Trusted Host Certificate Authority Dialog

In the Name box, specify an identifying name for this CA. The name you chose will appear in the list of saved CAs. The identifying name can be anything you like. It’s there so that if you store multiple certificates you can tell which is which later when you want to edit or delete them. It also appears in the session log when a server presents a certificate signed by that CA.

Use Browse button next to Public key edit box to load the CA’s public key from a file, or paste it directly into the edit box. If your organization signs its host keys, they will publish the public key of their CA so that SSH users can include it in their configuration.

In the Valid hosts this key is trusted to certify box, configure at least one hostname wildcard to say what servers WinSCP should trust this CA to speak for. For example, suppose you work for Example Corporation (example.com), and the Example Corporation IT department has advertised a CA that signs all the Example internal machines’ host keys. Then probably you want to trust that CA to sign host keys for machines in the domain example.com, but not for anything else. So you might enter *.example.com into the Valid hosts box.

It’s important to limit what the CA key is allowed to sign. Don’t just enter * in that box! If you do that, you’re saying that Example Corporation IT department is authorized to sign a host key for anything at all you might decide to connect to – even if you’re connecting out of the company network to a machine somewhere else, such as your own personal server. So that configuration would enable the Example IT department to act as a “man-in-the-middle” between your WinSCP process and your server, and listen in to your communications – exactly the thing SSH is supposed to avoid.

So, if the CA was provided to you by the sysadmins responsible for example.com (or whatever), make sure WinSCP will only trust it for machines in the example.com domain.

The simplest thing you can enter in the Valid hosts this key is trusted to certify edit box is just a hostname wildcard such as *.example.com. This matches any host in any subdomain, so both ssh.example.com and login.dept.example.com would match, but prod.example.net would not.

But you can also enter multiple host name wildcards, and port number ranges, and make complicated Boolean expressions out of them using the operators && for “and”, || for “or”, ! for “not”, and parentheses.

For example, here are some other things you could enter.

• *.foo.example.com || *.bar.example.com. This means the CA is trusted to sign the host key for a connection if the host name matches *.foo.example.com or it matches *.bar.example.com. In other words, the CA has authority over those two particular subdomains of example.com, but not for anything else, like www.example.com.
• *.example.com && ! *.extrasecure.example.com. This means the CA is trusted to sign the host key for a connection if the host name matches *.example.com but does not match *.extrasecure.example.com. (Imagine if there was one top-secret set of servers in your company that the main IT department didn’t have security clearance to administer.)
• *.example.com && port:22. This means the CA is trusted to sign the host key for a connection if the host name matches *.example.com and the port number is 22. SSH servers running on other ports would not be covered.
• (*.foo.example.com || *.bar.example.com) && port:0-1023. This matches two subdomains of example.com, as before, but also restricts the port number to the range 0–1023.

A certificate configuration expression consists of one or more individual requirements which can each be a hostname wildcard, a single port number, or a port number range, combined together with these Boolean operators.

Unlike other languages such as C, there is no implied priority between && and ||. If you write A && B || C (where A, B and C are some particular requirements), then WinSCP will report a syntax error, because you haven’t said which of the && and || takes priority tightly. You will have to write either (A && B) || C, meaning “both of A and B, or alternatively just C”, or A && (B || C) (“A, and also at least one of B and C”), to make it clear.

RSA keys can be used to generate signatures with a choice of secure hash function. Typically, any version of OpenSSH new enough to support certificates at all will also be new enough to avoid using SHA-1, so the default settings of accepting the more modern SHA-256 and SHA-512 should be suitable for nearly all cases. For completeness, however, you can configure which types of RSA signature WinSCP will accept in a certificate from a CA using an RSA key.1