Use a random number to generate a self-signed certiciate for chromoting

Use a random number to generate a self-signed certiciate for chromoting

Chromoting host to use a random number to generate self-signed certificate.
This method is still not optimal, in case of collision SSLServerSocketNSS will
fail to start due to NSS rejecting the certificate.

Using a random number is a temporary solution until we can assign certificates
to the host.

BUG=70013
TEST=Connect to the same chromoting host after client is disconnected.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=72745

[wtc, 2011-01-20 01:28:26]

hclam: a certificate needs to be uniquely identified by the
issuer + serial number pair.  Therefore, if the issuer is
the same, the serial numbers must be different for different
certificates.

So, another option is to vary the issuer.  Right now it's
hardcoded to be "CN=chromoting".  Perhaps the hostname should
be part of the issuer name.

Still, using a random serial number is a good way to avoid
collisions.

[wtc, 2011-01-20 01:33:05]

LGTM.

http://codereview.chromium.org/6315009/diff/1/remoting/protocol/jingle_sessio...
File remoting/protocol/jingle_session_manager.cc (right):

http://codereview.chromium.org/6315009/diff/1/remoting/protocol/jingle_sessio...
remoting/protocol/jingle_session_manager.cc:7: #include
"remoting/protocol/jingle_session_manager.h"
Nit: the Style Guide recommends that this header be listed
first, before C and C++ system headers.  So <limits> should
be listed after this line.

http://codereview.chromium.org/6315009/diff/1/remoting/protocol/jingle_sessio...
remoting/protocol/jingle_session_manager.cc:289: base::RandInt(1,
std::numeric_limits<int>::max()),
This is correct.  But it uses only half of the possible
range (because 'int' is signed).

Alternatively, since the serial_number parameter is uint32,
you can also call base::RandUint64() and truncate the return
value to uint32.

[Sergey Ulanov, 2011-01-20 02:04:24]

LGTM