Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The TLS protocol only allows for certificates to be exchanged, not raw public keys. Even "PGP keys" (if you wanted to replace X.509 with <a href="http://tools.ietf.org/html/rfc5081" rel="nofollow noreferrer">OpenPGP for authentication in TLS</a>, which is much less supported) are in fact certificates (they're the signed combination of a public key and a set of identifiers and attributes).</p> <p>This being said, you can perform client authentication using self-signed client certificates and rely on their public keys (<strong>but you will need to verify this public key against something your server already knows, such as a known list</strong>). You need to understand the security implications for implementing this first. This is not quite the same problem as self-signed server certificates. (I'd suggest keeping a more traditional approach to verifying the server certificate.)</p> <p>You can make the client send a self-signed certificate (possibly using <a href="https://serverfault.com/a/382018/47187">certain tricks regarding the CA list advertised by the server</a>) and either perform the verification in the TLS stack or later in the application.</p> <p>Note that many application containers (e.g. Tomcat/Jetty in Java) expect the SSL/TLS layer to verify the client certificate. Hence, if you skip the authentication there (and prefer to do it later on within the container or as part of the application), many application frameworks will be confused. You need to be quite careful to make sure that authentication is actually performed somewhere before performing any action that requires authentication in your application.</p> <p>For example, it can be OK to have a trust manager that lets any client certificate through in Tomcat/Jetty, but you can't rely on the <code>javax.servlet.request.X509Certificate</code> request attribute to have been verified in any way (which most frameworks would otherwise expect). You'd need to implement some verification logic within your application: for example, having a filter before any authenticated feature that compares the public key in this client certificate with your known list of public keys (or however you want to match the public key to an identifier). Alternatively, you can also perform this verification within your custom trust manager (in Java), this will require less work within the applications.</p> <p>You could do something similar in an Apache Httpd + PHP setup (for example), using <code>SSLVerifyClient optional_no_ca</code>. Again, your PHP application could not rely on the certificate having been verified, so you would have to implement so verification there too.</p> <p><strong>Don't do any of this unless you understand at which stage the certificate information you get has been verified.</strong></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload