In reproducing this to investigate, I notice that I have my keychain configured to “Confirm before allowing access.” So when I perform the find-internet-password
locally with the -g
flag, I get a dialog box stating security wants to use your confidential information stored in “smtp.gmail.com” in your keychain. If I click “Allow” then it works, if I click “Deny” it fails similarly to the ssh
case, with a return code of 51
.
When I try the command remotely via ssh
, the -g
immediately results in failure, with the status of 36
that you are reporting.
I suspect that this is because, when you ssh
in, there is no way for the system to pop up a dialog box allowing you to confirm that you want to allow the security
command to access this information.
I was able to get the command to work while connected by ssh
by first clicking the “Always Allow” option when running the command locally. This updates the permissions in Keychain so that I no longer need to respond to the dialog (even locally), which allows it to work remotely too.
I don’t know if this will be entirely helpful to you, however, as I think it means you will need to preemptively grant the security
program access to any keychain items you may want to access remotely. It may be possible to write a script to do this?
If you are experimenting with this manually and later want to revoke this access, you can go to the affected item in Keychain Access, choose Get Info and look at the Access Control tab. You will see an entry for security
there, which you can delete:
Best Answer
GuyGizmo's answer doesn't seem to work with Xcode 10.1 tools on macOS 10.14.4. I pulled this way together after a few tries.
Since I was trying to find out when my developer code signing certificate expires from the command line, I could readily look at apps that I had signed:
That tells you a certain amount about the app, and extracts the embedded signing certificate (without its private key, so there's no need for passwords) to a file called
codesign0
in the current directory, in DER format. The other certificates in the chain of trust are extracted tocodesign1
,codesign2
and so on, for as many as are needed. It's probably best to remove them once you've finished with them.You can then use the OpenSSL command-line tool to get the expiry date:
Which prints a result like:
Another way to get the same information from the
codesign0
file, in a format that may be easier to parse with a programming language, is:That will show you the beginning and ending dates in ASN.1 UTC time format, which is usually
YYMMDDhhmmssZ
in an Apple code signing certificate. Yes, the two-digit year does mean an ASN.1 UTC time wraps around every century.