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"
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 trying to connect via SSL to a PostgreSQL using FireDac in Delphi. I have followed the instructions at the following site:
https://www.howtoforge.com/postgresql-ssl-certificates
I have created all the certificates. Configured the postgreql.conf as specified so it points to the required files. Copied the specified files to the client machine and installed the root.crt certificate.
Via FireDAC's connection params I have specified the following:
Params.values[SSL_ca']:=sslCertsPath+'root.crt';
Params.values['SSL_cert']:=sslCertsPath+'postgresql.crt.';
Params.values['SSL_key']:=sslCertsPath+'postgresql.key';
I am getting a connection error re invalid client certificate. I am not sure which certificate it is referring to and why it is invalid. Am I specifying the correct client certificates by way of the connection's params? If so, any suggestions as to why I may be getting the error please?
OpenSSL verify against the root.crt and postgresql.crt confirms the certificate is ok.
After over 3 weeks of frustration trying to set up PostgreSQL with SSL using FireDAC, I have finally figured out what the problem is and what the solution is.
For anyone wishing to connect using FireDAC, the howtoforge guide (see link in original post) works fine.
However, do not use the FireDAC parameters in my original post. PostgreSQL does not use them. You need to use the PGAdvanced parameter.
But even after figuring this out, I still could not get it to work for weeks until after testing I got an error message which finally made it clear what I was doing wrong. On Windows PostgreSQL strips out path delimiters unless you escape them (this is not mentioned in the PostgreSQL or FireDAC help files as far as I can see).
Below is an example of the correct way to connect using FireDac paramaters for ssl
Params.values['PGAdvanced']:='sslmode=verify-ca sslrootcert=C:\\ProgramData\\MWC\\Viewer\\Certs\\root.crt sslcert=C:\\ProgramData\\MWC\\Viewer\\Certs\\postgresql.crt sslkey=C:\\ProgramData\\MWC\\Viewer\\Certs\\postgresql.key';
If you don't wish to use a root certificate set sslmode to require.
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 using lighty on an embedded device where power-users are allowed to manipulate the system configuration using an web interface. The users can upload an PEM file containing valid private key and certificate information.
Now I wonder how to avoid that lighty will not start if the file is corrupt? One idea is to check the file before installing it, but it seems that there is no easy solution.
My other idea is to configure lighty in a way that it will recognize the file is invalid (it does in fact) but it should not terminate. Instead it should run without SSL features, so HTTP only.
Is there a way to configure lighty for that? or is there a better solution?
This should provide just enough check options for your need
openssl verify --help
You could use a perlscript to comment out any ssl related config block if the cert check fails, but that is beyond this question.
Of course you need to edit the init/service script which starts lighttpd/lighttpd.service