Cleaner ignores hostnames in SSL certificates

[pmoravec]

User story: Cleaner was applied to a sosreport. Since the sosreport was taken from a RedHat distro, /etc/pki/consumer/cert.pem was collected by dnf plugin. The certificate file contains plain FQDNs. Example from my system (some.domain was manually obfuscated by myself):

# openssl x509 -in /etc/pki/consumer/cert.pem -text
..
        Issuer: C=US, ST=North Carolina, L=Raleigh, O=Katello, OU=SomeOrgUnit, CN=pmoravec-sat615.some.domain.redhat.com
..
            X509v3 Subject Alternative Name: 
                DirName:/O=RedHat/CN=5b9d4751-2720-42fa-846f-7bdd62074ab5, DirName:/CN=pmoravec-rhel9.some.domain.redhat.com
..
#

The file is not binary, so cleaner does not remove it. But the hostnames are straighforwardly "encoded" within the file.

Can be there some solution, at all? I ruled out a few ideas already..

Imho the best we can do is cleaner raising a warning "hey, I leave untouched a certificate that may contain sensitive info".

[pafernanr]

Not sure if this could fit:

• Replace cert.pem with cert.pem-text using the openssl x509 -in /etc/pki/consumer/cert.pem -text output and obfuscate it.

This implies *.pem files become "unusable" for openssl commands, although I guess this is expected/desired.

[pmoravec]

That sounds good to me, or at least I dont have a better idea. I think a good place for this would be around keep_binary_files test at

sos/sos/cleaner/__init__.py

Line 692 in 142ddb4

if (not self.opts.keep_binary_files and

. Sill I see some concerns:

• should we have a cmdline option to keep the certificate files and not malforming them, even in cleaner? Sometimes it is useful to get the cert file itself, not only its textual content.
• is there a reliable way to identify SSL certificates?
• what if cleaner fails to call openssl command or the tool isnt present..?

@TurboTurtle , does the idea from Pablo sound good to you?

[TurboTurtle]

I think it's a reasonable approach for when users definitely want that content, however I hesitate to make it a default because there are certainly environments/organizations out there that would not want any part of their certs discernable (whether or not that's a valid posture to take is tangental to what we're talking about here).

I like an approach where we have these options:

1. Remove cert bundles alongside binary files (even though they aren't really binary files)
2. Convert to text and obfuscate like above
3. Keep the cert bundles intact and unmodified

I'm not sure off the top of my head what the default should be though.

[pmoravec]

I would vote for

2. Convert to text and obfuscate like above

as the default. That means the data are not further usable for SSL purposes, while it still provides valuable information like expiration, key length, signature algorithm etc.

This option (regardless if default or not) should be also treated in a way if openssl x509 -in .. command fails, the certificate is removed (option 1.) and not kept (option 3). Rather be more safe and obscuring here.

@pafernanr , would you like to try implement this? If not, I can, for sure ;-)

[pafernanr]

@pmoravec I was thinking about how to implement it, IMO get the target-certfile-list is not easy. Search for file extensions is not accurate and requires extra resources. The best way I can think of is to let every plugin to define a few List-variables. E.g:

certificates_to_remove ['/etc/pki/consumer/key.pem', '/etc/vmware-tools/GuestProxyData/server/key.pem' ]
certificates_to_txt = ['/etc/pki/consumer/cert.pem']

There should be a post-report-execution action to transform/remove such certificate files.
The default behavior would be "3. Keep the cert bundles intact and unmodified", allowing plugins developers to decide what to do with their certificates, if List-vars are not defined then no action is taken. Obfuscation should work transparently on transformed text-certificate files.

If I'm not wrong this also aligns to @TurboTurtle's requirements.