Stephen Collyer wrote:
>Thiago Macieira wrote:
>Hmm, that sounds tricky so I've taken the simpler option of
>setting peerName() prior to calling startServerEncryption() and
>that seems to work (at least with a hard-coded peer name - I need
>to sort out the DNS lookup logic to get it to work for real).
>What is involved in implementing my own SSL-error verification ?
>Presumably I would have to replace the entire functionality of
Use ignoreSslErrors() and then compare the certificate that you received
from the client with what you expect.
Be careful that, if you use ignoreSslErrors(), QSslSocket will start
writing data that you have sent. So you shouldn't send anything until you
verify the certificate.
>Or because I didn't call setPeerName() which seems to fix
>BTW, what is the rationale for not setting peerName() in servers ?
>It seems that it is required for proper support of client certificates.
Because you're accepting the connection from the remote. In most cases, a
client's IP address cannot be determined beforehand.
In general, when a server requests clients to present certificates, they
will try and validate the certificate against a precise certificate
authority: yours. This way, you can be sure that the client is who is
he's supposed to be.
>>> Does the Qt SSL logic support the SAN field in certs, BTW ?
>> I did not understand this.
>SSL certs can have a Subject-Alternative-Names field, which
>some clients check in addition to the Common Name. So if the
>CN is "abc.domain.com" and the SAN field contains "localhost",
>"steves_machine", then the cert will be valid for all three
>peer names. This requires that the client actually checks the
>SAN field, of course, and I guess that the Qt code doesn't ?
There are checks for alternate names, correct.
Thiago José Macieira - thiago.macieira AT trolltech.com
Trolltech, a Nokia Company
Sandakerveien 116, NO-0402 Oslo, Norway