Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As long as you keep the private key safe (and the CA keeps their signing key safe), "company Y" doesn't need any other information to <em>authenticate</em> you. In other words, they can be sure that a request really came from the subject named in the certificate.</p> <p>However, this doesn't mean that you are <em>authorized</em> to do anything. In practice, most systems that use client certificates have an "out of band" process where you provide the "subject" distinguished name that is specified in the client certificate, and the system assigns some privileges to that name. </p> <p>In fact, because of some practical limitations, some systems actually associate the privileges with the certificate itself (using the issuer's name and the certificate serial number). This means that if you get a new certificate, you might have to re-enroll it, even if it has the same subject name.</p> <p>A certificate only assures a relying party you have a certain name. That party needs some additional mechanism to determine what you are allowed to do.</p> <hr> <p>Unlike authentication mechanisms based on "secret" (symmetric) keys&mdash;e.g., passwords&mdash;a server only needs public information for asymmetric authentication. A private signing key should <em>never</em> be disclosed; it's certainly not necessary for client authentication.</p> <p>With symmetric, password-based authentication, the client and server get access to the same string of bytes&mdash;the secret key. With public-key cryptography, only the public key of a key pair is disclosed. The corresponding private key is never disclosed, and no practical method for figuring out the private key from the public key has been discovered.</p> <p>As long as you keep your private key safe, the server at company Y cannot forge requests that appear to come from you.</p> <hr> <p>Client authentication replay attacks are defeated by requiring the client to digitally sign a message that includes a number randomly generated by the server for each handshake (this is the "random" member of the "ServerHello" message). If the packet used to authenticate the client in a previous session were re-used, a server will be unable to verify the signature, and won't authenticate the replay attack.</p> <p><a href="http://tools.ietf.org/html/rfc2246#appendix-F.1.1.2" rel="nofollow noreferrer">RFC 2246, Appendix F.1.1.2</a> might be a more helpful reference&mdash;especially the third paragraph:</p> <blockquote> <p>When RSA is used for key exchange, clients are authenticated using the certificate verify message (see Section 7.4.8). The client signs a value derived from the master_secret and all preceding handshake messages. These handshake messages include the server certificate, which binds the signature to the server, and ServerHello.random, which binds the signature to the current handshake process.</p> </blockquote>
    singulars
    1. This table or related slice is empty.
    1. POClient-side SSL theoretical question
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USerickson
    1. USerickson
    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. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COvery helpful, i added some more detail to my question (see original question), per your follow-up, can you possibly check it out?
      singulars
      1. PO
      1. USkvista
    2. COthanks again, one more clarification above, any response appreciated...
      singulars
      1. PO
      1. USkvista
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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