Server ssh certificate chain against MITM attacks?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







3















During first contact with a server via ssh, the server's public key of the chosen key algorithm is presented to the user to validate it. After validation, the result is usually saved into the ~/.ssh/known_hosts file to counter later MITM attacks.



$ ssh host.example.com
The authenticity of host 'host.example.com (1.2.3.4)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)?


This obviously won't help against a MITM attack on the first connection and does just move the problem to the user, who now has to have some process in place to verify the presented public key - and we all know how that ends.



Is it possible to distribute ssh server keys signed with a corporate CA to counter MITM-attacks on first contact? The public-private-key infrastructure with certificate chain supports this in general - but I have never seen it used in a corporate environment to secure ssh servers.



General idea would be to trust a CA key for a set of hosts:



trust *.example.com SHA256:<fingerprint(public key(corporate-ca))>


and every host that fist this and has been signed by the CA is trusted:



ca.example.com
+- host.example.com


This is similar to how HTTPS is secured, and since ssh uses the same underlying technology - is something like that already implemented in OpenSSH and I just didn't find it?










share|improve this question































    3















    During first contact with a server via ssh, the server's public key of the chosen key algorithm is presented to the user to validate it. After validation, the result is usually saved into the ~/.ssh/known_hosts file to counter later MITM attacks.



    $ ssh host.example.com
    The authenticity of host 'host.example.com (1.2.3.4)' can't be established.
    ECDSA key fingerprint is SHA256:xxxxxxxxxxxxx.
    Are you sure you want to continue connecting (yes/no)?


    This obviously won't help against a MITM attack on the first connection and does just move the problem to the user, who now has to have some process in place to verify the presented public key - and we all know how that ends.



    Is it possible to distribute ssh server keys signed with a corporate CA to counter MITM-attacks on first contact? The public-private-key infrastructure with certificate chain supports this in general - but I have never seen it used in a corporate environment to secure ssh servers.



    General idea would be to trust a CA key for a set of hosts:



    trust *.example.com SHA256:<fingerprint(public key(corporate-ca))>


    and every host that fist this and has been signed by the CA is trusted:



    ca.example.com
    +- host.example.com


    This is similar to how HTTPS is secured, and since ssh uses the same underlying technology - is something like that already implemented in OpenSSH and I just didn't find it?










    share|improve this question



























      3












      3








      3


      2






      During first contact with a server via ssh, the server's public key of the chosen key algorithm is presented to the user to validate it. After validation, the result is usually saved into the ~/.ssh/known_hosts file to counter later MITM attacks.



      $ ssh host.example.com
      The authenticity of host 'host.example.com (1.2.3.4)' can't be established.
      ECDSA key fingerprint is SHA256:xxxxxxxxxxxxx.
      Are you sure you want to continue connecting (yes/no)?


      This obviously won't help against a MITM attack on the first connection and does just move the problem to the user, who now has to have some process in place to verify the presented public key - and we all know how that ends.



      Is it possible to distribute ssh server keys signed with a corporate CA to counter MITM-attacks on first contact? The public-private-key infrastructure with certificate chain supports this in general - but I have never seen it used in a corporate environment to secure ssh servers.



      General idea would be to trust a CA key for a set of hosts:



      trust *.example.com SHA256:<fingerprint(public key(corporate-ca))>


      and every host that fist this and has been signed by the CA is trusted:



      ca.example.com
      +- host.example.com


      This is similar to how HTTPS is secured, and since ssh uses the same underlying technology - is something like that already implemented in OpenSSH and I just didn't find it?










      share|improve this question
















      During first contact with a server via ssh, the server's public key of the chosen key algorithm is presented to the user to validate it. After validation, the result is usually saved into the ~/.ssh/known_hosts file to counter later MITM attacks.



      $ ssh host.example.com
      The authenticity of host 'host.example.com (1.2.3.4)' can't be established.
      ECDSA key fingerprint is SHA256:xxxxxxxxxxxxx.
      Are you sure you want to continue connecting (yes/no)?


      This obviously won't help against a MITM attack on the first connection and does just move the problem to the user, who now has to have some process in place to verify the presented public key - and we all know how that ends.



      Is it possible to distribute ssh server keys signed with a corporate CA to counter MITM-attacks on first contact? The public-private-key infrastructure with certificate chain supports this in general - but I have never seen it used in a corporate environment to secure ssh servers.



      General idea would be to trust a CA key for a set of hosts:



      trust *.example.com SHA256:<fingerprint(public key(corporate-ca))>


      and every host that fist this and has been signed by the CA is trusted:



      ca.example.com
      +- host.example.com


      This is similar to how HTTPS is secured, and since ssh uses the same underlying technology - is something like that already implemented in OpenSSH and I just didn't find it?







      ssh ssl-certificate certificate-authority pki






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Feb 15 at 9:57









      HorstKevin

      1093




      1093










      asked Feb 15 at 9:35









      LarsLars

      369319




      369319






















          3 Answers
          3






          active

          oldest

          votes


















          3














          This is possible.



          Quoting the docs:



          AUTHORIZED_KEYS FILE FORMAT
          [...]
          cert-authority
          Specifies that the listed key is a certification authority (CA)
          that is trusted to validate signed certificates for user authentication.

          Certificates may encode access restrictions similar to these key options.
          If both certificate restrictions and key options are present, the most
          restrictive union of the two is applied.


          Steps to achieve this:




          • Generate a SSH Server CA Key:


          ssh-keygen -f server_ca



          • Generate a SSH Server Host Key:


          ssh-keygen -t ecdsa -b 521 -N '' -C 'somehost.example.com' -f ssh-ecdsa.key



          • Sign the host key with your ca key:


          ssh-keygen -s server_ca -I somehost.example.com -h -n 'somehost.example.com,somehost,<list of SANs>,<list of IPv4>,<list of IPv6>' -V +3650d ssh-ecdsa.key



          • Deploy the host key + certificate in your SSH Server (copy cert & key to /etc/ssh, edit /etc/ssh/sshd_config):


          HostCertificate /etc/ssh/ssh-ecdsa.key-cert.pub
          HostKey /etc/ssh/ssh-ecdsa.key



          • Set up your clients to trust your CA key to identify hosts (~/.ssh/known_hosts)


          @cert-authority example.com ssh-rsa AAAA[...]


          Notes:




          • It's not compatible to regular X.509 PKIs.

          • Maintaining (and consuming) a key revocation list (KRL) is needed. See the OpenSSH Cookbook for details.

          • Cumbersome, consider using something like Vault and a configuration management tool to automate this.

          • Have a look at the Monkeysphere project for a take on the "web of trust for SSH" idea.


          Find more information in the links below, especially on how to set this up to sign keys for users.



          Links:




          • https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Public_Key_Authentication

          • https://www.freebsd.org/cgi/man.cgi?sshd(8)

          • https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-certificate-authority.html

          • https://web.monkeysphere.info/






          share|improve this answer

































            3














            An different approach is to publish SSH key finger prints in DNS as SHFP records:

            See RFC 4255 https://tools.ietf.org/html/rfc4255



            That makes verification of the public key an automated process once you set VerifyHostKeyDNS to yes in the (global) ssh client defaults.






            share|improve this answer
























            • That's really nice solution as well... Thanks!

              – Lars
              Feb 18 at 7:28











            • You need to have DNSSEC enabled for the zone, otherwise these records can be filtered or spoofed.

              – Patrick Mevzek
              Feb 19 at 21:42



















            2














            If it's in a corporate environment, you can also have a centrally managed list of SSH keys of all your machines that you can then deploy to /etc/ssh/ssh_known_hosts on all clients using your favourite configuration management tool. This can also be used for direct host-based authentication between the machines. (Managing SSH host keys centrally is also useful to prevent unwanted host key changes when a server gets reinstalled.)



            Of course, this approach only works for "internal" SSH access where both the client and the server is under your control. If you need arbitrary external users to SSH in (and you can't just give them the known_hosts file), SSHFP records in DNSSEC-secured DNS are probably the way to go.






            share|improve this answer


























              Your Answer








              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "2"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f954093%2fserver-ssh-certificate-chain-against-mitm-attacks%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              3 Answers
              3






              active

              oldest

              votes








              3 Answers
              3






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              3














              This is possible.



              Quoting the docs:



              AUTHORIZED_KEYS FILE FORMAT
              [...]
              cert-authority
              Specifies that the listed key is a certification authority (CA)
              that is trusted to validate signed certificates for user authentication.

              Certificates may encode access restrictions similar to these key options.
              If both certificate restrictions and key options are present, the most
              restrictive union of the two is applied.


              Steps to achieve this:




              • Generate a SSH Server CA Key:


              ssh-keygen -f server_ca



              • Generate a SSH Server Host Key:


              ssh-keygen -t ecdsa -b 521 -N '' -C 'somehost.example.com' -f ssh-ecdsa.key



              • Sign the host key with your ca key:


              ssh-keygen -s server_ca -I somehost.example.com -h -n 'somehost.example.com,somehost,<list of SANs>,<list of IPv4>,<list of IPv6>' -V +3650d ssh-ecdsa.key



              • Deploy the host key + certificate in your SSH Server (copy cert & key to /etc/ssh, edit /etc/ssh/sshd_config):


              HostCertificate /etc/ssh/ssh-ecdsa.key-cert.pub
              HostKey /etc/ssh/ssh-ecdsa.key



              • Set up your clients to trust your CA key to identify hosts (~/.ssh/known_hosts)


              @cert-authority example.com ssh-rsa AAAA[...]


              Notes:




              • It's not compatible to regular X.509 PKIs.

              • Maintaining (and consuming) a key revocation list (KRL) is needed. See the OpenSSH Cookbook for details.

              • Cumbersome, consider using something like Vault and a configuration management tool to automate this.

              • Have a look at the Monkeysphere project for a take on the "web of trust for SSH" idea.


              Find more information in the links below, especially on how to set this up to sign keys for users.



              Links:




              • https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Public_Key_Authentication

              • https://www.freebsd.org/cgi/man.cgi?sshd(8)

              • https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-certificate-authority.html

              • https://web.monkeysphere.info/






              share|improve this answer






























                3














                This is possible.



                Quoting the docs:



                AUTHORIZED_KEYS FILE FORMAT
                [...]
                cert-authority
                Specifies that the listed key is a certification authority (CA)
                that is trusted to validate signed certificates for user authentication.

                Certificates may encode access restrictions similar to these key options.
                If both certificate restrictions and key options are present, the most
                restrictive union of the two is applied.


                Steps to achieve this:




                • Generate a SSH Server CA Key:


                ssh-keygen -f server_ca



                • Generate a SSH Server Host Key:


                ssh-keygen -t ecdsa -b 521 -N '' -C 'somehost.example.com' -f ssh-ecdsa.key



                • Sign the host key with your ca key:


                ssh-keygen -s server_ca -I somehost.example.com -h -n 'somehost.example.com,somehost,<list of SANs>,<list of IPv4>,<list of IPv6>' -V +3650d ssh-ecdsa.key



                • Deploy the host key + certificate in your SSH Server (copy cert & key to /etc/ssh, edit /etc/ssh/sshd_config):


                HostCertificate /etc/ssh/ssh-ecdsa.key-cert.pub
                HostKey /etc/ssh/ssh-ecdsa.key



                • Set up your clients to trust your CA key to identify hosts (~/.ssh/known_hosts)


                @cert-authority example.com ssh-rsa AAAA[...]


                Notes:




                • It's not compatible to regular X.509 PKIs.

                • Maintaining (and consuming) a key revocation list (KRL) is needed. See the OpenSSH Cookbook for details.

                • Cumbersome, consider using something like Vault and a configuration management tool to automate this.

                • Have a look at the Monkeysphere project for a take on the "web of trust for SSH" idea.


                Find more information in the links below, especially on how to set this up to sign keys for users.



                Links:




                • https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Public_Key_Authentication

                • https://www.freebsd.org/cgi/man.cgi?sshd(8)

                • https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-certificate-authority.html

                • https://web.monkeysphere.info/






                share|improve this answer




























                  3












                  3








                  3







                  This is possible.



                  Quoting the docs:



                  AUTHORIZED_KEYS FILE FORMAT
                  [...]
                  cert-authority
                  Specifies that the listed key is a certification authority (CA)
                  that is trusted to validate signed certificates for user authentication.

                  Certificates may encode access restrictions similar to these key options.
                  If both certificate restrictions and key options are present, the most
                  restrictive union of the two is applied.


                  Steps to achieve this:




                  • Generate a SSH Server CA Key:


                  ssh-keygen -f server_ca



                  • Generate a SSH Server Host Key:


                  ssh-keygen -t ecdsa -b 521 -N '' -C 'somehost.example.com' -f ssh-ecdsa.key



                  • Sign the host key with your ca key:


                  ssh-keygen -s server_ca -I somehost.example.com -h -n 'somehost.example.com,somehost,<list of SANs>,<list of IPv4>,<list of IPv6>' -V +3650d ssh-ecdsa.key



                  • Deploy the host key + certificate in your SSH Server (copy cert & key to /etc/ssh, edit /etc/ssh/sshd_config):


                  HostCertificate /etc/ssh/ssh-ecdsa.key-cert.pub
                  HostKey /etc/ssh/ssh-ecdsa.key



                  • Set up your clients to trust your CA key to identify hosts (~/.ssh/known_hosts)


                  @cert-authority example.com ssh-rsa AAAA[...]


                  Notes:




                  • It's not compatible to regular X.509 PKIs.

                  • Maintaining (and consuming) a key revocation list (KRL) is needed. See the OpenSSH Cookbook for details.

                  • Cumbersome, consider using something like Vault and a configuration management tool to automate this.

                  • Have a look at the Monkeysphere project for a take on the "web of trust for SSH" idea.


                  Find more information in the links below, especially on how to set this up to sign keys for users.



                  Links:




                  • https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Public_Key_Authentication

                  • https://www.freebsd.org/cgi/man.cgi?sshd(8)

                  • https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-certificate-authority.html

                  • https://web.monkeysphere.info/






                  share|improve this answer















                  This is possible.



                  Quoting the docs:



                  AUTHORIZED_KEYS FILE FORMAT
                  [...]
                  cert-authority
                  Specifies that the listed key is a certification authority (CA)
                  that is trusted to validate signed certificates for user authentication.

                  Certificates may encode access restrictions similar to these key options.
                  If both certificate restrictions and key options are present, the most
                  restrictive union of the two is applied.


                  Steps to achieve this:




                  • Generate a SSH Server CA Key:


                  ssh-keygen -f server_ca



                  • Generate a SSH Server Host Key:


                  ssh-keygen -t ecdsa -b 521 -N '' -C 'somehost.example.com' -f ssh-ecdsa.key



                  • Sign the host key with your ca key:


                  ssh-keygen -s server_ca -I somehost.example.com -h -n 'somehost.example.com,somehost,<list of SANs>,<list of IPv4>,<list of IPv6>' -V +3650d ssh-ecdsa.key



                  • Deploy the host key + certificate in your SSH Server (copy cert & key to /etc/ssh, edit /etc/ssh/sshd_config):


                  HostCertificate /etc/ssh/ssh-ecdsa.key-cert.pub
                  HostKey /etc/ssh/ssh-ecdsa.key



                  • Set up your clients to trust your CA key to identify hosts (~/.ssh/known_hosts)


                  @cert-authority example.com ssh-rsa AAAA[...]


                  Notes:




                  • It's not compatible to regular X.509 PKIs.

                  • Maintaining (and consuming) a key revocation list (KRL) is needed. See the OpenSSH Cookbook for details.

                  • Cumbersome, consider using something like Vault and a configuration management tool to automate this.

                  • Have a look at the Monkeysphere project for a take on the "web of trust for SSH" idea.


                  Find more information in the links below, especially on how to set this up to sign keys for users.



                  Links:




                  • https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Public_Key_Authentication

                  • https://www.freebsd.org/cgi/man.cgi?sshd(8)

                  • https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-certificate-authority.html

                  • https://web.monkeysphere.info/







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Feb 15 at 13:47

























                  answered Feb 15 at 13:38









                  fuerofuero

                  6,0332836




                  6,0332836

























                      3














                      An different approach is to publish SSH key finger prints in DNS as SHFP records:

                      See RFC 4255 https://tools.ietf.org/html/rfc4255



                      That makes verification of the public key an automated process once you set VerifyHostKeyDNS to yes in the (global) ssh client defaults.






                      share|improve this answer
























                      • That's really nice solution as well... Thanks!

                        – Lars
                        Feb 18 at 7:28











                      • You need to have DNSSEC enabled for the zone, otherwise these records can be filtered or spoofed.

                        – Patrick Mevzek
                        Feb 19 at 21:42
















                      3














                      An different approach is to publish SSH key finger prints in DNS as SHFP records:

                      See RFC 4255 https://tools.ietf.org/html/rfc4255



                      That makes verification of the public key an automated process once you set VerifyHostKeyDNS to yes in the (global) ssh client defaults.






                      share|improve this answer
























                      • That's really nice solution as well... Thanks!

                        – Lars
                        Feb 18 at 7:28











                      • You need to have DNSSEC enabled for the zone, otherwise these records can be filtered or spoofed.

                        – Patrick Mevzek
                        Feb 19 at 21:42














                      3












                      3








                      3







                      An different approach is to publish SSH key finger prints in DNS as SHFP records:

                      See RFC 4255 https://tools.ietf.org/html/rfc4255



                      That makes verification of the public key an automated process once you set VerifyHostKeyDNS to yes in the (global) ssh client defaults.






                      share|improve this answer













                      An different approach is to publish SSH key finger prints in DNS as SHFP records:

                      See RFC 4255 https://tools.ietf.org/html/rfc4255



                      That makes verification of the public key an automated process once you set VerifyHostKeyDNS to yes in the (global) ssh client defaults.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Feb 15 at 14:10









                      HBruijnHBruijn

                      56.8k1190150




                      56.8k1190150













                      • That's really nice solution as well... Thanks!

                        – Lars
                        Feb 18 at 7:28











                      • You need to have DNSSEC enabled for the zone, otherwise these records can be filtered or spoofed.

                        – Patrick Mevzek
                        Feb 19 at 21:42



















                      • That's really nice solution as well... Thanks!

                        – Lars
                        Feb 18 at 7:28











                      • You need to have DNSSEC enabled for the zone, otherwise these records can be filtered or spoofed.

                        – Patrick Mevzek
                        Feb 19 at 21:42

















                      That's really nice solution as well... Thanks!

                      – Lars
                      Feb 18 at 7:28





                      That's really nice solution as well... Thanks!

                      – Lars
                      Feb 18 at 7:28













                      You need to have DNSSEC enabled for the zone, otherwise these records can be filtered or spoofed.

                      – Patrick Mevzek
                      Feb 19 at 21:42





                      You need to have DNSSEC enabled for the zone, otherwise these records can be filtered or spoofed.

                      – Patrick Mevzek
                      Feb 19 at 21:42











                      2














                      If it's in a corporate environment, you can also have a centrally managed list of SSH keys of all your machines that you can then deploy to /etc/ssh/ssh_known_hosts on all clients using your favourite configuration management tool. This can also be used for direct host-based authentication between the machines. (Managing SSH host keys centrally is also useful to prevent unwanted host key changes when a server gets reinstalled.)



                      Of course, this approach only works for "internal" SSH access where both the client and the server is under your control. If you need arbitrary external users to SSH in (and you can't just give them the known_hosts file), SSHFP records in DNSSEC-secured DNS are probably the way to go.






                      share|improve this answer






























                        2














                        If it's in a corporate environment, you can also have a centrally managed list of SSH keys of all your machines that you can then deploy to /etc/ssh/ssh_known_hosts on all clients using your favourite configuration management tool. This can also be used for direct host-based authentication between the machines. (Managing SSH host keys centrally is also useful to prevent unwanted host key changes when a server gets reinstalled.)



                        Of course, this approach only works for "internal" SSH access where both the client and the server is under your control. If you need arbitrary external users to SSH in (and you can't just give them the known_hosts file), SSHFP records in DNSSEC-secured DNS are probably the way to go.






                        share|improve this answer




























                          2












                          2








                          2







                          If it's in a corporate environment, you can also have a centrally managed list of SSH keys of all your machines that you can then deploy to /etc/ssh/ssh_known_hosts on all clients using your favourite configuration management tool. This can also be used for direct host-based authentication between the machines. (Managing SSH host keys centrally is also useful to prevent unwanted host key changes when a server gets reinstalled.)



                          Of course, this approach only works for "internal" SSH access where both the client and the server is under your control. If you need arbitrary external users to SSH in (and you can't just give them the known_hosts file), SSHFP records in DNSSEC-secured DNS are probably the way to go.






                          share|improve this answer















                          If it's in a corporate environment, you can also have a centrally managed list of SSH keys of all your machines that you can then deploy to /etc/ssh/ssh_known_hosts on all clients using your favourite configuration management tool. This can also be used for direct host-based authentication between the machines. (Managing SSH host keys centrally is also useful to prevent unwanted host key changes when a server gets reinstalled.)



                          Of course, this approach only works for "internal" SSH access where both the client and the server is under your control. If you need arbitrary external users to SSH in (and you can't just give them the known_hosts file), SSHFP records in DNSSEC-secured DNS are probably the way to go.







                          share|improve this answer














                          share|improve this answer



                          share|improve this answer








                          edited Feb 15 at 14:52

























                          answered Feb 15 at 14:47









                          TooTeaTooTea

                          1214




                          1214






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Server Fault!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f954093%2fserver-ssh-certificate-chain-against-mitm-attacks%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              Human spaceflight

                              Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

                              張江高科駅