I am wondering what are the GUID suffixes for the RSA key container files stored in the machine and user key container stores. I cannot identify some of these as key containers through CAPI/CNG, although I'll expose my case using command line tools instead. Commands below are for PowerShell in an elevated prompt. On most machines, the GUID suffix is the same for all these file names, but on this one there are four different GUIDs, while the API is returning only keys with only one. What is this GUID? I do not like random secrets stored by I do not know what on my machine; are they safe to delete?
The content of the machine store directory is:
> ls -n $env:ProgramData\Microsoft\Crypto\Rsa\MachineKeys | sort { "$_"[-3..-1] }
d1f9044f5d7345da71c0d2efd2e4f59e_e9f96f2e-b8b7-49b2-85a5-840195eca603
d6d986f09a1ee04e24c949879fdb506c_a4dc5a56-574d-4e4b-ba8d-d88984f9a6c5
6de9cb26d2b98c01ec4e9e8b34824aa2_a4dc5a56-574d-4e4b-ba8d-d88984f9a6c5
76944fb33636aeddb9590521c2e8815a_a4dc5a56-574d-4e4b-ba8d-d88984f9a6c5
d6d986f09a1ee04e24c949879fdb506c_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
d1f9044f5d7345da71c0d2efd2e4f59e_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
76944fb33636aeddb9590521c2e8815a_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
6de9cb26d2b98c01ec4e9e8b34824aa2_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
ba8e1b9b5510957b3af7b811f05660de_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
d1f9044f5d7345da71c0d2efd2e4f59e_c6a7fc9d-32a6-41e4-afd5-7dc7b822029e
I sorted the list by the last three characters, so that it's easy to see in a glance that there are 4 distinct GUID suffixes to the key container files. Now let's enumerate the key reported by all installed CSPs. I'll get the list of providers, and later the list of each provider's keys using the certutil tool that comes with Windows. Its output requires some regex magic for parsing, which is not essential, just convenient:
> certutil -csplist | sls '^Provider Name: (.*)' | %{ $_.Matches[0].Groups[1].Value }
Microsoft Base Cryptographic Provider v1.0
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider
Microsoft Base DSS Cryptographic Provider
[...snip...]
The output for a single key lists the name, flags and the key container ID, the latter matching respective file name in the above directory (of course, we can see more keys from additional KSPs, smart cards, TPM etc.). Example for one provider (the -q makes some providers fail silently instead of asking for user's action, such as inserting a SmartCard):
> certutil -key -q
Microsoft Strong Cryptographic Provider:
iisConfigurationKey
6de9cb26d2b98c01ec4e9e8b34824aa2_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
RSA
AT_KEYEXCHANGE
iisWasKey
76944fb33636aeddb9590521c2e8815a_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
[...snip...]
Some key names are just GUIDs too, but if we grep out only the lines that start with at the least 20 hex digits, there will be only the IDs listed. So all key IDs from all providers can be concisely shown with:
> certutil -csplist | sls '^Provider Name: (.*)' | %{ $_.Matches[0].Groups[1].Value } |
%{ certutil -key -q -csp "$_" } | sls '^\s+[0-9a-f]{20}.+' | sort -u
597367cc37b886d7ee6c493e3befb421_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
6de9cb26d2b98c01ec4e9e8b34824aa2_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
76944fb33636aeddb9590521c2e8815a_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
ba8e1b9b5510957b3af7b811f05660de_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
d6d986f09a1ee04e24c949879fdb506c_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
f0e91f6485ac2d09485e4ec18135601e_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
Here are actually 2 more keys than there are in the MachineKeys directory (they come from the KSP, in fact, certutil -key -csp KSP shows them, if you are wondering). But the fact is they all have the same GUID suffix _f7fe3b04-ef9b-4b27-827f-953c5743e2ec.
The machine was installed by the vendor (an HP notebook, to be exact). This is unlike other machines, that we assemble or buy barebone and install and configure by ourselves. And I am working with some sensitive data sometimes, so I am indeed paranoid vetting the software thoroughly before allowing machines to access sensitive data.
The OS is Windows 10, if that matters, but the same type of storage has not changed from Windows 7, AFAIK, even with the introduction of the new CNG API in 8.0 (or 8.1?).
Just in case anyone would find useful a PowerShell snippet to readably list keys by provider, I used this command:
> certutil -csplist | sls '^Provider Name: (.*)' | %{ $_.Matches[0].Groups[1].Value } |
%{ Write-Host -for Yellow "`n$_"; certutil -key -q -csp "$_" }
Found the answer here: https://serverfault.com/a/642279/451491
The file naming convention is x_y, where x is a random GUID to
uniquely identify the key, and y is the machine GUID found at
HKLM\SOFTWARE\Microsoft\Cryptography.
Related
i try to monitor values with nagios over snmp from my two audiocodes SBCs (M500L).
For these i download two MIBs "AC-ALARM-MIB" + "IP-MIB_rfc4293" from https://github.com/librenms/librenms/tree/master/mibs/audiocodes rename it to .txt at the end and upload it to my ubuntu server in path /usr/share/snmp/mibs/.
Then i try to use the following command in command line.
snmpget -v3 -l authPriv -u xxxxxx -a SHA -A xxxxx -x AES -X xxxxx 123.456.789.100 AcAlarm:acActiveAlarmName
and i get the following output
AcAlarm::acActiveAlarmName = No Such Instance currently exists at this OID
I try to find out the OID from these in MIB Browser - seems like it is " .1.3.6.1.4.1.5003.11.1.1.1.1.5". When i use these OID i get same output.
Anyone has an idea?
SNMP treats all values as being entries in some database. OIDs are used to identify entries in this conceptual database. MIB files allow an SNMP manager to translate OIDs into a human-readable string, with an accompanying textual description.
The issue here is not that the MIB files are bad, or the OIDs are wrong, the problem is that, either the devices that hold this (imaginary) database do not support the entries you are trying to access, or that your user is not authorized to access those entries. A simple way to find out what OIDs are supported would be to do a full walk of the database, using something like snmpwalk <hostname> 1.3.6.1
According to the manual of ssh-keygen
, -k flag generates some KRL file. What do these KRL files mean and how I specify a KRL location while using this flag?
According to FreeBSD Manual Pages BSD General Commands Manual :
KEY REVOCATION LISTS
ssh-keygen is able to manage OpenSSH format Key Revocation Lists (KRLs).
These binary files specify keys or certificates to be revoked using a
compact format, taking as little as one bit per certificate if they are
being revoked by serial number.
KRLs may be generated using the -k flag. This option reads one or more
files from the command line and generates a new KRL. The files may ei-
ther contain a KRL specification (see below) or public keys, listed one
per line. Plain public keys are revoked by listing their hash or con-
tents in the KRL and certificates revoked by serial number or key ID (if
the serial is zero or not available).
Revoking keys using a KRL specification offers explicit control over the
types of record used to revoke keys and may be used to directly revoke
certificates by serial number or key ID without having the complete orig-
inal certificate on hand. A KRL specification consists of lines contain-
ing one of the following directives followed by a colon and some direc-
tive-specific information.
serial: serial_number[-serial_number]
Revokes a certificate with the specified serial number. Serial
numbers are 64-bit values, not including zero and may be ex-
pressed in decimal, hex or octal. If two serial numbers are
specified separated by a hyphen, then the range of serial numbers
including and between each is revoked. The CA key must have been
specified on the ssh-keygen command line using the -s option.
id: key_id
Revokes a certificate with the specified key ID string. The CA
key must have been specified on the ssh-keygen command line using
the -s option.
key: public_key
Revokes the specified key. If a certificate is listed, then it
is revoked as a plain public key.
sha1: public_key
Revokes the specified key by its SHA1 hash.
KRLs may be updated using the -u flag in addition to -k. When this op-
tion is specified, keys listed via the command line are merged into the
KRL, adding to those already there.
It is also possible, given a KRL, to test whether it revokes a particular
key (or keys). The -Q flag will query an existing KRL, testing each key
specified on the command line. If any key listed on the command line has
been revoked (or an error encountered) then ssh-keygen will exit with a
non-zero exit status. A zero exit status will only be returned if no key
was revoked.
My objective is to test whether a certain root certification authority is trusted by the active user. I currently have a working solution that I managed to piece together using several other answers1,2, but it seems very convoluted to me, so I'm asking for alternative (or at least, simplified) suggestions from people who (unlike me) know what they're doing.
I am assuming that this will be executed by a non-privileged user (i.e. one that cannot install new packages), so I would like to use utilities that are likely bundled with most unix/linux distros (unlike e.g. certutil). For this reason, the current solution uses awk, grep and openssl, which seem quite universal.
Another thing I should note is that I'm not concerned with the possible security implications that might arise from testing certificates the way I do.
Here's my current code:
awk -v cmd='openssl x509 -noout -issuer' '/BEGIN/{close(cmd)};{print | cmd}'
< /etc/ssl/certs/ca-certificates.crt
| grep -F 'issuer=C = US, O = company, CN = localhost, OU = engineering'
It uses awk in conjunction with openssl to iterate over all existing certificates, outputting their Issuer, then piping it to grep to test whether the required line exists.
The output I'm getting in the case of a positive match is the string I'm looking for, even though all I need is a binary answer (true/false, yes/no, 1/0, ...).
Any suggestion on how to achieve my goal in a simpler and/or more universal fashion?
You can spare the call to awk by processing all the certificates using openssl alone. According to this answer on Server Fault the following will use an intermediate conversion to provide the same amount of information (i.e. the issuer for each certificate in the input file) which can be filtered for the data you're looking for:
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
| openssl pkcs7 -print_certs -noout \
| grep '^issuer=/C=US/O=company/CN=localhost/OU=engineering'
I find this an improvement because it doesn't use a bulky call to awk (which would also be another dependency), and the output of pkcs7 seems much more machine-readable than the whitespace-ridden original output from x509.
Note that you can use the return value of the above grep call to tell whether the given root CA is trusted:
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
| openssl pkcs7 -print_certs -noout \
| grep -q '^issuer=/C=US/O=company/CN=localhost/OU=engineering' && echo 'Certificate found!'
I need to have a certificate's Friendly Name set to an empty value so in Certificate Console Friendly Name column would display <None>.
Using this code all I could get is just empty value in the column, not <None> I need.
gci "Cert:\LocalMachine\My" | ? {$_.Subject -like "CN=mycer*"} | % { $_.FriendlyName = '' }
I also tried $_.FriendlyName = $null which made no difference.
Strange thing - when I clear Friendly Name using console then from Powershell's perspective the value is '' as the following statement produces True: write-host ($_.FriendlyName -eq ''). However, the ''' value applied vice a versa doesn't provide the expected result.
Any help is greatly appreciated.
UPDATE and ANSWER:
As Kory Gill suggested in comments, certutil.exe is indeed the way to get what I need.
Having created an clear.inf file with content below
[Version]
Signature = "$Windows NT$"
[Properties]
11 =
and executed certutil.exe -repairstore -user my "serial number" clear.inf I managed to reset Friendly Name to <None> value.
As an alternative to the PowerShell cmdlet for managing certificates, which may have issues with some properties, one can use certutil.exe as well to manage certs. This is similar to using robocopy.exe instead of Copy-File. Use the tools that give you the desired results...
This link shows an example of how to use certutil to change the friendly name.
Example usage from that page is:
certutil.exe -repairstore my "{serialnumber}" "change-friendly-name.inf"
where the inf file looks like:
[Version]
Signature = "$Windows NT$"
[Properties]
11 = "{text}new friendly name"
See also certutil reference.
I want to know if there is a command that will list the information that can be found in the Digital Signatures section of the properties of a .exe. Particularly I want to be able to grab the Name of the signer. Is there a command that will generate that information for me?
To get the subject name from the signer certificate used to create an Authenticode signature, you could use Get-AuthenticodeSignature:
PS > $asig = Get-AuthenticodeSignature 'C:\Windows\System32\xcopy.exe'
PS > $asig.SignerCertificate.Subject
CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
You're probably interested in the Common Name (CN), and maybe the Organization name (O). You can parse the Distinguished Name from Subject into its components to get the Common Name:
PS > $asig = Get-AuthenticodeSignature 'C:\Windows\System32\xcopy.exe'
PS > $dnDict = ($asig.SignerCertificate.Subject -split ', ') |
foreach `
{ $dnDict = #{} } `
{ $item = $_.Split('='); $dnDict[$item[0]] = $item[1] } `
{ $dnDict }
PS > $dnDict['CN']
Microsoft Windows
PS > $dnDict['O']
Microsoft Corporation
The Sigcheck tool from Microsoft's Windows Sysinternals can dump the information out. Using the -c command line option formats the output in a csv format which can be piped to a file for later processing.
Sigcheck is a command-line utility that shows file version number, timestamp information, and digital signature details, including certificate chains.
try signtool.exe. use following reference regarding signtool,
https://msdn.microsoft.com/en-us/library/windows/desktop/aa387764(v=vs.85).aspx
this is to output on the console:
writeln(GETDOSOutput('powershell write-host =(Get-AuthenticodeSignature ''C:\Program Files\Streaming\maxbox4\maXbox4.exe'').SignerCertificate.Subject', 'C:\'));