Confusion about TLS Based Protocols and Certificates and SSH Keys and Host Keys

Hey guys my https site validates happily but an ssh command still needs to be manually added to known hosts. Seems the certificate is not being seen by ssh:

$> ssh
The authenticity of host ‘ (118.209.XXX.XXX)’ can’t be established.
ECDSA key fingerprint is SHA256:iARZxKGq+R1rNgjcFuPOzqXsJc0CYbxTjgowb1krt00.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘’ (ECDSA) to the list of known hosts.

I’ve tried:
./letsencrypt-auto certonly --standalone --agree-tos -d

Hi @rupert160

Maybe you are having a slow day (had one today as well - was blaming a load balancer when i pointed all traffic to another server :frowning: )

SSL Certificates are use with HTTPS and other TLS Based Protocols (Mail, FTP over SSL)

SSH Protocol Uses the Concept of SSH Keys.

SSH Keys and SSL Certificates are not related at all.

In SSH you have the concept of a host key which basically identifies your host.

Have a quick recap:

This is not really a Let’s Encrypt topic but I thought I would help out anyway :smiley:


Thanks, @ahaw021.

This was previously discussed at

Interestingly, there is a concept of an “SSH certificate”, but it is not at all widely used.

A difference between the two applications is that the certificates for use with TLS (like HTTPS) are often meant to be accepted and validated by “the public” while SSH host keys are often meant to be accepted and validated by a very limited group of authorized users (who may have a pre-existing relationship with the server operator, or even be server operators). I think that’s why a similar PKI for SSH keys has not become widespread.

hi @schoen

Thanks for sharing. Learn soemething new every day!

Usually our customers know the host RSA keys (this is part of the onboarding process)


Customer A

  • please give me your public SSH key
  • here is my host key - if you see anything but my host key do not trust it
  • ssh allows for the host key to be specified in the connect string (which is equivalent to PKI validation)


“open sftp://xxx:xxxx@YYYY/ -hostkey=”“ssh-rsa 2048 02:12:8a:3a:4d:e4:60:1b:9a:3c:13:33:f3:85:e7:7f”""


@ahaw021 - Thanks for your response. Upon further reading I have found an slight contradiction that was actually contained in your link (as mentioned by @schoen). - “Host Certificates”

OpenSSH does use Public key encryption keys as “host certificates” however they are not the X.509 standard and the Let’s Encrypt keys will not be able to be used (OpenSSH uses another format for signing keys).

It’s a shame because, it would seem to me, if the TECTIASSH ssh method was used, the Letsencrypt validated host might have been used as a signing CA (given we have both Public and Private Keys) we could have registed our own host as the local CA cert with a complete chain of authority. Full certification with a Certificate Authority for SSH. Seems we’re all waiting for to be solved…

hi @rupert160

The challenge is two fold. As tectia mentioned you can have X509 certificates however the clients have to be written to recognize and verify these.

As far as I am aware most clients don’t support this option. I don’t believe most servers don’t implement this either.

So you are stuck with even if you can do it (which you can) you will need to use clients which support this.

If you do want to use X509 certificate then something like Tectia SSH Server and clients are a good option.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.