This answer only provides an answer of a way to get the SHA1 code via Keychain Access UI: Retrieve a certificate's SHA1 hash from macOS Keychain Access
Is there a way to see the SHA1 hash for the certificates via the security dump-keychain command or something similar?
You can use the security cli to find a certificate. Providing the right query and the right parameters will output the SHA-1 hash.
security find-certificate -Z
You can alter the find-certificate command to perform a better selection. The -Z parameter adds the SHA-1 and SHA-256 hash to the output.
One final remark, SHA-1 is considered insecure since 2005. I highly recommend switching to SHA-256, which conveniently is also outputted via the -Z parameter
Related
I'm starting a coding bootcamp pretty soon and in a tutorial they have given me they tell me to only accept an rsa key fingerprint of SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
I keep getting an ED25519 key fingerprint of SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Does it really matter if I accept this instead of the rsa key fingerprint?
It used to be that GitHub offered only RSA and DSA keys as host keys. However, that changed recently, and GitHub now offers ECDSA and Ed25519 keys as well (and has removed the DSA key, since it's insecure). On a fresh system, the latest versions of OpenSSH will prefer the Ed25519 key over the RSA key, which is normal and fine.
The GitHub API meta endpoint lists both the correct fingerprints and the actual SSH keys themselves. From a cursory glance, you appear to have the correct fingerprint, but you can verify that by pasting the fingerprint from the API at the prompt.
There is no reason to force the use of an RSA key here, but if you really want to do so, you can run ssh -oHostKeyAlgorithms=rsa-sha2-512,rsa-sha2-256 -T git#github.com.
While in general, you should always verify the SSH key fingerprint, in this case, the fingerprint is correct but it's just a different key. You should let the maintainers of this tutorial know that their information is out of date and that they should update the documentation.
I have a dsc token, im aware that they can be only signing, or they can be signing and encryption. How do i check?
KeyUsageFlag for X509 certificate is a bitwise flag.
Please refer: X509KeyUsageFlags Enum
There can be a single certificate with both the flag set (addation of values for DigitalSignature and KeyEncipherment) i.e. 128 + 32 or two different certificates. This depends on how Certifying Authority choses to issue the certificate.
How do i check?
Method 1: You must have Smartcard or USB Token driver installed which pushesh Certificates in token to Windows Certificate Store on inserting the token. Then run certmgr.msc to open Certificate Manager; go to Personal Certificates, double click the required certificate to open the Certificate Details and check Key Usage property in Details tab. Values displayed here are in Hex. like: Digital Signature (80)
Method 2:
You may filter on key values and check as above.
Install Signer.Digital Browser Extension as described here
Once Extension is installed and available in the browser, open any site so that browser loads extension script and execute below commands from the console of the browser
SignerDigital.getSelectedCertificate("", 32) - to list only Encryption Certificates
SignerDigital.getSelectedCertificate("", 128) - to list only DigitalSignature Certificates.
Here 32 and 128 are X509KeyUsageFilter values as discussed above.
I would like to know whether it is possible to change the signature algorithm from SHA1 to SHA256 in Websphere Application Server V7.0.0.17. ? If yes, is there any link which explains this.
Yes it's possible. If you procured your certificates from a CA other than the one built into WAS, procure new ones. If you let WAS manage your PKI, follow the instructions here:
http://www-01.ibm.com/support/docview.wss?uid=swg21959568
To convert these certificates with the Administrative console click
Security > SSL certificate and key management > Manage FIPS. Then
click Convert Certificates
We are trying to implement the following workflow:
generate private key in browser, using window.crypto
create a PKCS10 certificate signing request in the browser
send the PKCS10 to a server
the server signs the request and returns an x509 certificate in PEM format
the browser stores the certificate for itself
The same thing already works using the keygen tag in the browser and using SPKAC instead of pkcs10. Now, however the browser does not store the certificate returned, just wants to save them. When we try to import the certificate to the browser by hand, we got "the private key for the certificate is missing or invalid".
We suspect that the private key generated by window.crypto.generateKey() does not get stored in the browser's keystore. How to get the private key stored in the keystore?
The implementation of the first two steps is based on http://blog.engelke.com/2014/08/23/public-key-cryptography-in-the-browser/
Update: As some browsers use the OS keystore, I am also looking into the possibility to save the key into the OS keystore through some other way.
What I have figured out so far:
Java cannot be used according to this question: Tell Java to use Windows keystore
In Windows one can use ActiveX controls.
Summary: Found no standard cross-browser and cross-OS way to generate and meaningfully use X509 certificates. There are combinations (new chrome versions (dropping keygen support) on non-windows OS) where there is no way to do this.
I set up SSH login for github using the following instructions, and although it works, I can't figure out why it works: https://help.github.com/articles/generating-ssh-keys/
My understanding of SSH is as follows: client creates a key pair, client gives public key to server, and when client wants to log in, he encrypts a message of server's choice using his private key to prove that he is really the client.
Now: I upload my public key XXX to Github. When I do "ssh -T git#github.com", Github has to know I am trying to log in as me, so that he can decrypt my message using XXX, right? So ssh has to send that information...but how does ssh know anything about Github, or what my username is? And what if I have multiple key pairs - which key would ssh use?
When you add your SSH public key to your GitHub account, you associate that key with your GitHub account.
By default, the command ssh -T git#github.com searches for id_dsa and id_rsa files. To confirm this, try ssh -T git#github.com -v.
If you have keys associated to different github accounts, you would have to specify with -i to use different accounts. ssh -T git#github.com -i /path/to/mykey
In short:
SSH client send public key to server
Server finds your name according to public key (unique), but needs to verify that you have also the private key, therefore he sends you a some message
Your client signs that message using your private key
Server verifies the signature and if it is valid, you are allowed access
This is based on public key cryptography, specially digital signature technique (google for more details).
In a shared-account scenario, authentication/authorization is handled by the application.
I'm not sure Github is using it, but one solution for non-shell account authorization is Gitosis, and it used for precisely the purpose you describe. There are separate key pairs for each user. This much is similar to how Github does things.
The basic notion of how Gitosis works (deferring the authentication and authorization to gitosis) is explained on the app readme page, but the mechanics may require a review of the source code. Based on a cursory examination, it looks like the mechanics of this method are mostly via git hooks on the server.