PostgreSQL connection require a valid client certificate - postgresql

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.

Related

How can i specify keytab file when connecting to postgres with golang pq using kerberos?

I am currently using golang pq library to connect to postgres database. I am successfully connecting using kerberos principal, but i can't figure out where can i specify keytab file to use to. In the source code it kinda happens magically, using some third-party library. It actually works, but i need to know for sure how does it know where my keytab is stored, so it can request initial ticket.
Usually Kerberos clients do not directly use a keytab; they expect the initial ticket to be already acquired and present in the environment. That is, you're expected to kinit before running the program, and afterwards the client's GSSAPI library looks for the KRB5CCNAME environment variable, which points at a file containing the ticket cache left by kinit.
(Normally with MIT Kerberos or Heimdal it could be many other things besides a file... but the 'pq' library uses a very minimal pure-Go Kerberos implementation which only accepts a traditional file-based ccache. So be careful if Krb5 on your distro was set up to use 'DIR' or 'KEYRING' or 'KCM' cache types, those aren't going to work here.)
If the initial ticket isn't present, the MIT Krb5 implementation will in fact automatically use a keytab to acquire the ticket if the KRB5_CLIENT_KTNAME environment variable is pointing to one. Unfortunately, the 'pq' library doesn't use the system Kerberos library, so that won't work here either. (But it also wouldn't work if your OS was using Heimdal Kerberos; it's a MIT-specific extension.)
So the approach that will always work is to set KRB5CCNAME to a temporary path, then use either kinit or k5start to acquire a ticket from the keytab, before running your program. (The k5start tool will also keep automatically renewing or re-acquiring the ticket before it expires, without needing to use cron.)
Really, the whole krb_unix.go file is disappointing. If they can call the native SSPI on Windows, surely they could call the native GSSAPI on Linux...

AWS AmazonS3Client request returns error "The remote certificate is invalid according to the validation procedure"

We have an application using AWS SDK AmazonS3Client to communicate with the S3 service to get files downloaded. With thousands of instances running fine, however, we got a few sites getting the following exception error message:
The remote certificate is invalid according to the validation procedure.
The versions of the AmazonSDK.S3.dll and AmazonS3.Core.dll we're using are 3.3.102.18 and 3.3.103.1 respectively. These had been running for over a year without problems until recently.
Has anyone else experienced the similar issue? What could be the root cause of the problem? How do we resolve it?
Thanks!
This has been determined as an issue with proxy server loaded with incorrect certificate from the service provider. So, not really the application issue.

Same p12 certificate, different trust chain on different machines, why?

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.

lighttpd - don't terminate on invalid ssl key/cert?

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

XPI signing linux no gui

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.