CSR creation with CN only about acme

[kelunik]

You're right, it could be reduced. The reason I put these values there is that otherwise it would be prefilled with strange values, that might not be the case with the always passed config now anymore.

Are there any known issues when adding additional properties?

[kelunik]

I think I will move the CSR generation out of that method anyway with 0.4.0

[dol]

Are there any known issues when adding additional properties?

The only issue I see is that to much information sent to the the ACME server. The current spec states the following:

The CSR encodes the client’s requests with regard to the content of the certificate to be issued. The CSR MUST indicate the requested identifiers, either in the commonName portion of the requested subject name, or in an extensionRequest attribute [RFC2985] requesting a subjectAltName extension.

If you extract the CSR generation a little hint. The CSR generation could also be done with a environment variable (kind of a strange thing built into the core of OpenSSL, but avoids the need of generating a temporary file). See https://gist.github.com/dol/e0b7f084e2e7158efc87 as an example.
An other hint. When using heredoc notation, I prefer the nowdoc notation to prevent possible inclusion of PHP variables. Most of the time heredoc ist just fine. It's only a security precaution.

[kelunik]

The current spec states the following

It doesn't say anything about additional fields.

See https://gist.github.com/dol/e0b7f084e2e7158efc87 as an example.

That's really strange, don't know which method I prefer.

An other hint. When using heredoc notation, I prefer the nowdoc notation to prevent possible inclusion of PHP variables. Most of the time heredoc ist just fine. It's only a security precaution.

Don't know which editor / IDE you use, but mine highlights variables in there, so accidental inclusion isn't that likely to happen. Additionally, it would also throw a notice because of undefined variables probably. :-)

[dol]

It's a matter of taste. Can't argue with that. ;-)