mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-09 08:10:09 +08:00
234a02b2a8
Get rid of VARATT_SIZE and VARATT_DATA, which were simply redundant with VARSIZE and VARDATA, and as a consequence almost no code was using the longer names. Rename the length fields of struct varlena and various derived structures to catch anyplace that was accessing them directly; and clean up various places so caught. In itself this patch doesn't change any behavior at all, but it is necessary infrastructure if we hope to play any games with the representation of varlena headers. Greg Stark and Tom Lane |
||
---|---|---|
.. | ||
Makefile | ||
README.sslinfo | ||
sslinfo.c | ||
sslinfo.sql.in | ||
uninstall_sslinfo.sql |
sslinfo - information about current SSL certificate for PostgreSQL ================================================================== Author: Victor Wagner <vitus@cryptocom.ru>, Cryptocom LTD E-Mail of Cryptocom OpenSSL development group: <openssl@cryptocom.ru> 1. Notes -------- This extension won't build unless your PostgreSQL server is configured with --with-openssl. Information provided with these functions would be completely useless if you don't use SSL to connect to database. 2. Functions Description ------------------------ 2.1. ssl_is_used() ~~~~~~~~~~~~~~~~~~ ssl_is_used() RETURNS boolean; Returns TRUE, if current connection to server uses SSL and FALSE otherwise. 2.2. ssl_client_cert_present() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ssl_client_cert_present() RETURNS boolean Returns TRUE if current client have presented valid SSL client certificate to the server and FALSE otherwise (e.g., no SSL, certificate hadn't be requested by server). 2.3. ssl_client_serial() ~~~~~~~~~~~~~~~~~~~~~~~~ ssl_client_serial() RETURNS numeric Returns serial number of current client certificate. The combination of certificate serial number and certificate issuer is guaranteed to uniquely identify certificate (but not its owner -- the owner ought to regularily change his keys, and get new certificates from the issuer). So, if you run you own CA and allow only certificates from this CA to be accepted by server, the serial number is the most reliable (albeit not very mnemonic) means to indentify user. 2.4. ssl_client_dn() ~~~~~~~~~~~~~~~~~~~~ ssl_client_dn() RETURNS text Returns the full subject of current client certificate, converting character data into the current database encoding. It is assumed that if you use non-Latin characters in the certificate names, your database is able to represent these characters, too. If your database uses the SQL_ASCII encoding, non-Latin characters in the name will be represented as UTF-8 sequences. The result looks like '/CN=Somebody /C=Some country/O=Some organization'. 2.5. ssl_issuer_dn() ~~~~~~~~~~~~~~~~~~~~ Returns the full issuer name of the client certificate, converting character data into current database encoding. The combination of the return value of this function with the certificate serial number uniquely identifies the certificate. The result of this function is really useful only if you have more than one trusted CA certificate in your server's root.crt file, or if this CA has issued some intermediate certificate authority certificates. 2.6. ssl_client_dn_field() ~~~~~~~~~~~~~~~~~~~~~~~~~~ ssl_client_dn_field(fieldName text) RETURNS text This function returns the value of the specified field in the certificate subject. Field names are string constants that are converted into ASN1 object identificators using the OpenSSL object database. The following values are acceptable: commonName (alias CN) surname (alias SN) name givenName (alias GN) countryName (alias C) localityName (alias L) stateOrProvinceName (alias ST) organizationName (alias O) organizationUnitName (alias OU) title description initials postalCode streetAddress generationQualifier description dnQualifier x500UniqueIdentifier pseudonim role emailAddress All of these fields are optional, except commonName. It depends entirely on your CA policy which of them would be included and which wouldn't. The meaning of these fields, howeer, is strictly defined by the X.500 and X.509 standards, so you cannot just assign arbitrary meaning to them. 2.7 ssl_issuer_field() ~~~~~~~~~~~~~~~~~~~ ssl_issuer_field(fieldName text) RETURNS text; Does same as ssl_client_dn_field, but for the certificate issuer rather than the certificate subject.