Which elliptic curve should I use?

You are misreading Bernstein and Lange's advice (admittedly, their presentation is a bit misleading, with the scary red "False" tags). What they mean is not that some curves are inherently unsafe, but that safe implementation of some curves is easier than for others (e.g. with regards to library behaviour when it encounters something which purports to be the encoding of a valid curve point, but is not).

What you really want is a curve such that:

• the software which you will entrust with your private key (your SSL server) is properly implemented and will not leak details about your private key;
• interoperability will be achieved.

For a SSL server certificate, an "elliptic curve" certificate will be used only with digital signatures (ECDSA algorithm). The server will sign only messages that it generates itself; and, in any case, the only "private" operation involving a curve in ECDSA is multiplication of the conventional base point (hardcoded, since it is part of the curve definition, hence correct) by a random value that the server generates. Therefore, in your use case, there is no risk of private key leakage that would be specific to the used curve. If your SSL implementation is poor, it will be poor for all curves, not for just some of them.

"Interoperability" means that you would probably prefer it if SSL clients can actually connect to your server; otherwise, having a SSL server would be rather pointless. This simplifies the question a lot: in practice, average clients only support two curves, the ones which are designated in so-called NSA Suite B: these are NIST curves P-256 and P-384 (in OpenSSL, they are designated as, respectively, "prime256v1" and "secp384r1"). If you use any other curve, then some widespread Web browsers (e.g. Internet Explorer, Firefox...) will be unable to talk to your server.

Use P-256 to minimize trouble. If you feel that your manhood is threatened by using a 256-bit curve where a 384-bit curve is available, then use P-384: it will increases your computational and network costs (a factor of about 3 for CPU, a few extra dozen bytes on the network) but this is likely to be negligible in practice (in a SSL-powered Web server, the heavy cost is in "Web", not "SSL").

I'd say stick to secp521r1 - even DJB says P-521 is pretty nice prime, and it's also supported in every modern crypto library.

In the same time, we should push forward adoption of non-NIST curves like Curve25519, which will be fully rigid, less prone to implementation errors and may become nice alternative for those who need faster solutions than secp521r1.

At least do not use the secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1 curves. they have a too small size for security application according to NIST recommendation!