@stpierre @fennm @AlexanderS anyone have thoughts on this? I'm really not sure if we should do this by default or perhaps just have it configurable via bcfg2.conf. Without this, one has to modify SSLCA.py to get the plugin working with the default openssl configuration on CentOS 6.

If the default can't be changed in another openssl config file, then it sounds like this is necessary. That said, it seems like it will probably result in all SSL certs being regenerated, so that's less than awesome. I hate to add an option for this, though, since the option would basically have to be actually_work_on_centos6 = True, and would only be useful for people upgrading from previous releases who didn't want their certs regenerated.

So I'd definitely be fine adding this to master. And if there's no more elegant way to do it, then I guess I kind of have to be fine adding it to maint -- breaking CentOS 6 isn't really an option.

The default can certainly be changed in openssl.cnf but I guess the point is one could want UTF-8 or some other string mask. I suppose making it configurable via bcfg2.conf might be the best option. At least then it would be documented and not just throw some useless SSL error.

@stpierre Why would this cause all certs to be regenerated? Wouldn't it just cause new CSRs to use the string_mask setting?

Sorry, you're right -- I wasn't thinking correctly about how SSLCA verifies certs.

If this can indeed be changed at a global level in openssl.cnf, then it seems like the only use case for needing a configurable string mask in Bcfg2 would be where you need one global default, but a different specific value for all Bcfg2-generated certs. That's a pretty marginal case. I'd say let's just merge the code as-is for now, so that Bcfg2 works out of the box. In the long run, it'd probably be a better approach to provide for arbitrary openssl configuration on a per-cert basis in Bcfg2, but that's a big feature.

👍

The problem arises because the openssl.cnf and the temporary config used by SSLCA contain different string_mask settings. So, setting the openssl.cnf to something (in this case, the default for CentOS 6 changed to utf-8) and not changing the corresponding setting in the code will result in very odd SSL error messages.

The messages are confusing because it will be something to the effect of "State Texas doesn't match Texas" since the encoding doesn't match but the error message is just the printed string.

Oh, ewwwwwwwwwwwwwww.

So then does this fix the issue for CentOS 6, but create the issue for
distros without string_mask=utf8only in openssl.cnf?

On Tue, Apr 28, 2015 at 9:28 AM, Sol Jerome [email protected]
wrote:

The problem arises because the openssl.cnf and the temporary config used
by SSLCA contain different string_mask settings. So, setting the
openssl.cnf to something (in this case, the default for CentOS 6 changed to
utf-8) and not changing the corresponding setting in the code will result
in very odd SSL error messages.

The messages are confusing because it will be something to the effect of
"State Texas doesn't match Texas" since the encoding doesn't match but the
error message is just the printed string.

—
Reply to this email directly or view it on GitHub
#272 (comment).

Chris St. Pierre

Quite possibly. Which is why maybe we should leave the default as-is but make it configurable?

How insane would it be to discover the default and use it?

On Tue, Apr 28, 2015 at 9:33 AM, Sol Jerome [email protected]
wrote:

Quite possibly. Which is why maybe we should leave the default as-is but
make it configurable?

—
Reply to this email directly or view it on GitHub
#272 (comment).

Chris St. Pierre

I don't think it'd be terrible. Let me take a look and see if that's a viable option.

Do we need this on master? Looks like the code changed a bit, but the configuration settings are still present: https://github.com/Bcfg2/bcfg2/blob/master/src/lib/Bcfg2/Server/Plugins/Cfg/CfgSSLCACertCreator.py#L69

I think we simply can drop the config file and use the system default (or even better: use the config file of the ca). The subject and the subjectAltNames can be specified on the command line with -subj. This way, we could use the auto detection of openssl itself.