I decided to install Gentoo and it is suggested to verify the cryptographic signature of downloaded files and the checksum. So I went through 100 pages of PGP4Win manual, trying to figured out how to import keys and validate the signature. I have managed to import the keys but I would need to know if it is OK that the signature appears to be in order only when I verify the key's fingerprint. When I just import keys, the signature is invalid.
Another weird thing was that when I compared the checksum of livecd.iso and digests.asc file with WinMD5 checksum was different, so does it mean that downloaded image is corrupted?
Thank you for help
Related
Like many I have received the MSB3325 strong naming error, I am targeting a pfx file and have tried to install the certificate directly to the CSP at the given container. The certificate is installed on the machine I am working on.
I generated the CSR through OpenSSL and received a p7b from a Certificate Authority, which I then converted to pfx with the key used in generating the CSR (I have also tried using online converters from different CAs to ensure I was not messing up the conversion through OpenSSL). I can confirm the pfx certificate contains the same key.
The sn -i cert.pfx VS_KEY_XXXXXXXXXXXXXXXX succeeds in pairing to the container but I get the exact same error and a failed build. I have tried many times to recreate the pfx and delete the container to pair to the new one. Initially I did not sign a password to the certificate (just pressed enter) but I have also tried giving it one, it made no difference.
I am trying to sign a WPF project and so far have been frustratingly unsuccessful.
Am I missing something? Many hours of research and all results come up to use the sn -i command to fix the problem.
I was trying to do an npm install today and ran into an error that looks like this:
The authenticity of host 'github.com (140.82.114.3)' can't be established <trash due to npm overwriting part of the line>
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
I have redacted the actual fingerprint but it was hex digits. In another question some of the answers establish that you should verify the authenticity of this key here. But when I go to this page I see keys in a totally different format:
SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 (RSA)
SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM (ECDSA)
SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (Ed25519)
I'm assuming since the message I saw mentioned ECDSA I should be trying to compare it to the second value, but beyond this, how do I get this value in the xx:xx:xx... format? You would assume that something important like this would be easy to compare so I'm a bit puzzled as to why there seems to be some excessive friction.
The format you're seeing for your fingerprints is the legacy hex format using MD5. Because MD5 is insecure and no longer suitable for use, since OpenSSH 6.8, fingerprints are printed using SHA-256 and base64. SHA-256 is presently considered secure and is a good choice for a cryptographic hash function.
This probably means that you're using a very old version of OpenSSH, possibly on an unsupported operating system, such as CentOS 6. If your OS is no longer supported, you should upgrade to one receiving security updates for everyone's benefit.
If in the meantime you still need to access GitHub, you can download the actual keys (as well as the fingerprints) from the GitHub API. If you save the ECDSA key into a file, say key, then you can run ssh-keygen -l -f key and it will print the fingerprint for that key in a format you can use.
I am working on a Nativescript-Angular application, I need to send one parameter of my web-request encrypted. We are using RSA encryption in all other platforms.
I have searched a lot on the internet regarding the same, I have already tried the node-RSA from npmjs.com but it gives
Failed to Find module: "Crypto"
I have a p12 file. This was generated from a DigiCert p7b.
When I import this into my personal store on one machine (windows server, using certificates mmc) it shows me one chain when I view the path.
Using the same file, I import into my personal store on a different machine (also windows, using certs mmc). On this one I see a different path (and in this case it has an expired hop)
Specifically, two hops above my cert the divergence occurs.
Why does this happen? Is there anything I can do to influence that chain (remember its the same p12 that is creating different paths)?
I should also say, I am no expert in this area. I'm a developer that muddles through these security issues when needed.
I had the same issue. Two different windows 2008 r2 servers, same certificate. After standard OS patching one of the servers was sending only the first layer of certificate trust chain (number 0), so the openssl client was failing with the message:
verify error:num=21:unable to verify the first certificate
No idea what was the root cause. I tried to
reassign certificate in IIS
reimport certificate
restart IIS
with no success. What finally helped to fix the issue was the server reboot...
Closing this out.
I'm still a little foggy on why things were working the way they did but some things made sense.
It seems the .p12 was created from a p7b that included some of the intermediate certs. One of the included intermediates was the bad one. This explains why the chain was bad on one machine.
Still not sure how I was able to see a good chain on different machine but I understand why I saw the bad one. It seems the good chain was the fluke and the bad chain should have been expected (I originally assumed the opposite).
I created a new .p12 without the intermediates. Cleaned up all the bad intermediates that were previously imported from the first .p12 in both service user and local machine stores. All seems to be working as expected now with same valid chain on all machines.
I'm trying to sign an XPI on linux (no gui) using the NSS cert db (cert8.db and key3.db) i copied from another server of mine, on which I can sign XPI's just fine.
On the new box I can sign with a brand new test certificate ok, but when i try to use the old cert db, it complains with:
signtool: PROBLEM signing data (Unknown issuer)
Certutil lists the cert im trying to use with a * and the CA is present in there as well.
Is this cert db transferable between computers like this? Or are there any other files I have to setup?
TIA
Mike
im not sure if this is what you need, but here it is: http://www.mercille.org/snippets/xpiSigning.php
If the certificate chain has an intermediate CA that also needs to be there.
NSS is rather picky when it comes to the chain and also needs the certs to have been marked as trusted.