Parameters to create a self-signed DSA certificate on Ubuntu 12.04?

Question

I would like to create a self-signed DSA certificate on Ubuntu 12.04 for use with a webserver and TLS 1.2 (HTTPS) connection.

I found that you can run the following command to create an RSA one:

openssl genrsa -out server.key 3072

However I need the following properties:

• 3072 bit key length using the regular DSA algorithm (not ECDSA)
• Using SHA2 cryptographic hash function with 384 bits
• Using "perfect forward secrecy" option
• Assign AES 256 as the first order of preference for the symmetric cipher
• No encryption for the private key required (to allow for unattended reboots).

Can someone help me with the parameters to do the following options above?

When a TLS session is initiated, how do you make sure it generates a new random signature value k each time? This is apparently critical to the security of the algorithm. Or is that automatic with OpenSSL?

I have found this TLS 1.2 cipher suite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 here how do I tell it to use that?

Thanks in advance.

Solution 1

Whatever you're doing, there's a pretty good chance you're doing it wrong based on the way you framed this question. If you found a blog post somewhere telling you that you needed to do this-or-that, don't just follow it without really knowing what it says. The reason why I say this is because most of the features you've asked for have nothing to do with creating a self-signed DSA certificate.

Instead, post a question asking about what you're actually trying to accomplish. It may be that the solution is not what you think it is.

But since you asked, here's how you generate a self-signed DSA certificate of 3072 bits:

openssl dsaparam -out params.pem 3072
openssl gendsa -out key.pem params.pem
openssl req -new -key key.pem -out req.pem
openssl x509 -req -in req.pem -signkey key.pem -out certificate.cer

Solution 2

Although SHA-384 can be used with DSA, there is no standard OID for such a combination, so OpenSSL won't be able to encode the "signature algorithm" part of your self-signed certificate. Standard OID have been defined for DSA with SHA-1, SHA-224 and SHA-256 only. For your self-signature, you will have to relax your "SHA-384 only" requirement. Since the self-signature has exactly zero cryptographic value anyway (it is there only because a certificate has a non-optional field for the "signature") and could be replaced with some random bytes of approximately the right size, this should be no hardship.

Similarly, DSA had first been defined to use a modulus in the 512 to 1024 bits range, then a modulus of exactly 1024 bits, no less and no more. Recent versions of the standard (FIPS 186-4) allow for a longer modulus, with restrictive choices: 1024, 2048 and 3072 bits only, with a subgroup size of 160, 224 or 256 bits (see page 15 for allowed combinations). Basically, using a modulus of size other than 1024 bits will imply interoperability issues (already using DSA will imply interoperability issues, because nobody does that in practice, so this support is, at best, poorly tested in deployed implementations).

(Incidentally, this means that using with DSA a hash function with an output larger than 256 bits is totally useless, since security will be limited to that of a 256-bit group, i.e. the extremely reasonable "128 bits" security level.)

Generation of the random k value for each signature is automatically done by OpenSSL so you do not have to worry about it (it is already hard to do correctly; if library users had to do it themselves, it would simply never be done correctly).

OpenSSL allows for the configuration of many cipher suites; see the documentation. In SSL, traditionally, the server follows the client preferences for cipher suite selection, but OpenSSL (the library) to enforce the server preferences (i.e. to force the cipher suite to be a specific one, as long as the client supports it, even if it did not appear first in the list sent by the client). Note that OpenSSL is a library: you use it only through some application code which uses OpenSSL, and you can configure OpenSSL's behaviour only through the configuration options of that application code, which may or may not give you leverage to apply arbitrary SSL-level options.