I am trying to load SSL certificate from java keystore to db2 dbm.
I did below steps:
Step 1: List certificates in truststore
$ keytool -list -v -keystore db-truststore
Enter keystore password:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 2 entries
Alias name: caintermediate
Creation date: May 24, 2018
Entry type: trustedCertEntry
...
...
Alias name: carootcert
Creation date: May 24, 2018
Entry type: trustedCertEntry
Step 2: Exported these certificates to files
keytool -export -alias carootcert -keystore db-truststore -file rootcert.pem
Enter keystore password:
Certificate stored in file <rootcert.pem>
keytool -export -alias caintermediate -keystore db-truststore -file intermediatecert.pem
Enter keystore password:
Certificate stored in file <intermediatecert.pem>
Step 3: created key database:
gsk8capicmd_64 -keydb -create -db "dbclient.kdb" -pw "passw0rd" -stash
Step 4: Added certificate files to key database
gsk8capicmd_64 -cert -add -db /full-path/dbclient.kdb -pw passw0rd -label carootcert -file rootcert.pem
gsk8capicmd_64 -cert -add -db /full-path/dbclient.kdb -pw passw0rd -label caintermediate -file intermediatecert.pem
Step 5: Added catalog:
db2 => catalog TCPIP NODE phdbdev REMOTE bldbz173038.cloud.dst.ibm.com SERVER 60443 SECURITY SSL
DB20000I The CATALOG TCPIP NODE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache is
refreshed.
db2 => catalog DATABASE phdbdev AT NODE phdbdev AUTHENTICATION SERVER
DB20000I The CATALOG DATABASE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache is
refreshed.
Step 6: Updated gdm
db2 update dbm cfg using SSL_CLNT_KEYDB /full-path/dbclient.kdb
SQL5133N The configuration parameter was not updated because the specified
value is not valid. Specified value: "0". Configuration parameter name:
"fcm_buffer_size".
Further investigation as suggested:
$ db2level
DB21085I This instance or install (instance name, where applicable: "vizeet")
uses "64" bits and DB2 code release "SQL11010" with level identifier
"0201010F".
Informational tokens are "DB2 v11.1.0.0", "s1606081100", "DYN1606081100AMD64",
and Fix Pack "0".
Product is installed at "/home/vizeet/sqllib".
$ db2 get dbm cfg | grep 'Node type'
Node type = Enterprise Server Edition with local and remote clients
$ db2 get dbm cfg | grep FCM
Number of FCM buffers (FCM_NUM_BUFFERS) = AUTOMATIC(4096)
FCM buffer size (FCM_BUFFER_SIZE) = 0
Number of FCM channels (FCM_NUM_CHANNELS) = AUTOMATIC(2048)
FCM parallelism (FCM_PARALLELISM) = AUTOMATIC(1)
db-truststore works properly with db2 drivers.
Unable to resolve this issue. Kindly help.
Related
When i try to import certificate on server 2012 it say password incorrect.
I have check this post:
"The password you entered is incorrect" when importing .pfx files to Windows certificate store
And i exported:
openssl.exe pkcs12 -in 'C:\cert.p12' -out C:\key.pem And created the new cert: openssl.exe pkcs12 -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -in 'C:\key.pem' -out 'C:\newcert.pfx' -name "newcert"
But when i try to import in server 2012 keep saying password incorrect.
The top answer in that post adds -nomac, which you didn't. Instead of turning off the MAC entirely, you could also try -macalg sha1.
--Something witty here questioning the use of a 10 year old OS (that only has 13 months of security updates remaining)--
For those who need it, i finally got it. Before execute the command from the other post, you have to export .key and .crt from your .p12 or .pfx certificate.
I am using command line tool "keytool" to create a key pair in softhsm.
I have added security.provider in java.security.
# List of providers and their preference orders (see above):
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI
security.provider.11=sun.security.pkcs11.SunPKCS11
${java.home}/lib/security/pkcs11.cfg
and My pkcs11.cfg looks like
name = SoftHSM v2
library = C:/SoftHSM2/lib/softhsm2-x64.dll
slot = 0
While running
keytool.exe -keystore NONE -storetype PKCS11 -list
I am getting the error
keytool error: java.security.KeyStoreException: PKCS11 not found.
Can you please help?
I try to create a certificate for testing purposes in two steps. First, I create a self-signed certificate which establishes my own Certification Authority (CA). Second, I use that root certificate to sign a test server certificate which will be placed in personal certificate store. I open an administrative command prompt and enter the following:
Step 1:
MakeCert -pe -n "CN=TestCA" -b 01/01/2015 -e 01/01/2020 -ss my -sr currentuser -a sha256 -sky signature -len 2048 -r "TestCA.cer"
Step 2:
MakeCert -pe -n "CN=localhost" -b 01/01/2015 -e 01/01/2020 -eku 1.3.6.1.5.5.7.3.1 -in "TestCA" -is my -ir currentuser -ss my -sr currentuser -a sha256 -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -len 2048 "Localhost.cer"
Following those steps, everything works fine. After that, I try to install those certificates via c++ application. It seems to be fine when I check those certificates in certmgr.msc, however, client always fail to connect to server since then. After deleting certificate "localhost" from personal certificate store, then do step 2 using MakeCert.exe again. Client can success to connect to server. Maybe there is something important that I was missing. If anyone knows it, please give me some suggestions. By the way, my client and server are running in the same computer. My codes are shown below.
HCERTSTORE hMyCertStore = NULL;
if(hMyCertStore = CertOpenStore(
CERT_STORE_PROV_SYSTEM, // The store provider type
0, // The encoding type is
// not needed
NULL, // Use the default HCRYPTPROV
CERT_SYSTEM_STORE_CURRENT_USER, // Set the store location in a
// registry location
L"MY" // The store name as a Unicode
// string
))
{
printf("The system store was created successfully.\n");
}
else
{
printf("An error occurred during creation "
"of the system store!\n");
exit(1);
}
CRYPTUI_WIZ_IMPORT_SRC_INFO importSrc;
memset(&importSrc, 0, sizeof(CRYPTUI_WIZ_IMPORT_SRC_INFO));
importSrc.dwSize = sizeof(CRYPTUI_WIZ_IMPORT_SRC_INFO);
importSrc.dwSubjectChoice = CRYPTUI_WIZ_IMPORT_SUBJECT_FILE;
importSrc.pwszFileName = L"C:\\Temp\\MakeCert\\localhost.cer";
importSrc.pwszPassword = L"";
importSrc.dwFlags = CRYPT_EXPORTABLE | CRYPT_USER_PROTECTED;
if (CryptUIWizImport(CRYPTUI_WIZ_NO_UI,
NULL,
NULL,
&importSrc,
hMyCertStore) == 0)
{
printf("CryptUIWizImport error %d\n", GetLastError());
}
Any help would be greatly appreciated.
Clement
I've found the difference between MakeCert and my application. After installing by MakeCert, I opened certificate dialog's General tab, then I found there is a string "You have a private key that corresponds to this certificate, but using my application, there is no string in the dialog. I think that I've missed some steps during the install procedure. If anyone know, please give me some suggestion.
Thanks.
Clement
Previously we have one code signing cert, every thing working fine. Recently cert expired so we taken new cert from Comodo and released new build with that cert.
So here is the problem: Package Family Name Changed with that new cert, so I am not able to upgrade old installed apps with this new build packaged with new cert.
Need solution for this to maintain Package Family Name as constant or for new cert's also we need to provide upgrade for older apps.
How can we achieve this?
Error msg while upgrading package from PowerShell:
Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF3, Package failed
updates, dependency or conflict validation.
Windows cannot install package df70dbc9-455c-4c32-b052-7ac2943630b7_1.0.193.1_x64__qbsrcgy0j364g
because a different package df70dbc9-455c-4c32-b052-7ac2943630b7_1.0.0.191_x64__hs446qhh7vdt4
with the same name is already installed. Remove package
df70dbc9-455c-4c32-b052-7ac2943630b7_1.0.0.191_x64__hs446qhh7vdt4 before
installing.
NOTE: For additional information, look for [ActivityId]
b0deec37-ac10-0001-81fd-deb010acd101 in the Event Log or use the command line
Get-AppxLog -ActivityID b0deec37-ac10-0001-81fd-deb010acd101
At C:\Users\\Desktop\\myappName_1.0.193.1_x64_Test\Add-AppDevPackage.ps1:388 char:13
+ Add-AppxPackage -Path $DeveloperPackagePath.FullName -DependencyPath ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (C:\Users\myuser....193.1_x64.appx:String) [Add-AppxPackage], IOException
+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
Error: Could not install the app.
The Package Family Name (PFN) suffix (in your case hs446qhh7vdt4) is a hash of the certificate's subject (AKA subject name):
certutil -dump foo.pfx
Enter PFX password:
================ Certificate 0 ================
================ Begin Nesting Level 1 ================
Element 0:
Serial Number: xxxxxxxxxxxxxxxxx
Issuer: CN=Microsoft, O=Contoso, L=Redmond, S=Washington, C=US
NotBefore: 11/1/2016 12:00 AM
NotAfter: 11/1/2017 12:00 AM
Subject: CN=Microsoft, O=Contoso, L=Redmond, S=Washington, C=US <== THIS IS HASHED
If you make sure the new cert you generate has the same subject, you'll get the same PFN. Note that you might not be able to generate store certs from within Visual Studio (at the time of writing, it can't parse complex subjects like the one above with multiple 'parts' like CN=X, O=Y). In that case you'll have to create your own, but it must comply with the store validations.
Luckily, there's a simple command that generates the exact certificate you need. Open a Visual Studio developer prompt and run (one line):
makecert -sv foo.pvk -n "CN=Contoso, O=Contoso, L=Redmond, S=Washington, C=US"
foo.cer -b 11/01/2016 -e 11/01/2017 -r -cy end -a sha256 -eku 1.3.6.1.5.5.7.3.3
Make sure to replace the validity dates (no more than a year apart!) as well as the subject (taken from your previous cert using certutil -dump). The names of the output cert (cer) and private key (pvk) are meaningless. That command will generate foo.pvk and foo.cer, which you will then be able to combine to a pfx like so:
PVK2PFX -pvk foo.pvk -spc foo.cer -pfx foo.pfx
Another option for advanced generation
In case you have more advanced cert requirements, you should be able to use certreq (haven't tested it though). Create a file named cert.inf with the following contents:
[Version]
Signature = "$Windows NT$"
[Strings]
szOID_ENHANCED_KEY_USAGE = "2.5.29.37"
szOID_CODE_SIGNING = "1.3.6.1.5.5.7.3.3"
szOID_BASIC_CONSTRAINTS2 = "2.5.29.19"
[NewRequest]
Subject = "CN=Contoso, O=Contoso, L=Redmond, S=Washington, C=US"
Exportable = true
HashAlgorithm = Sha256
KeyLength = 2048
RequestType = Cert
ValidityPeriod = "Years"
ValidityPeriodUnits = "1"
[Extensions]
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_CODE_SIGNING%"
%szOID_BASIC_CONSTRAINTS2% = "{text}"
Replace the subject and validity period, and adjust any advanced settings you need per the docs (or more likely found on the web). Then do the following:
certreq -new cert.inf cert.cer
Double-click the resulting cert.cer and install it to the Trusted Root Certificate Authorities store (either user or machine).
certreq -accept -user cert.cer OR certreq -accept -machine cert.cer (depending on the store you picked in the previous step).
Go to the Personal store in the cert manager (user or machine scope, depending on what you picked above) and find the cert you just installed. Double-click it and copy the serial number from the details tab (I encountered some voodoo here where the cert would only show up after a long time, or after I installed a different cert (with a different subject name).
certutil -exportpfx -p "YOUR_PFX_PASS" my SERIAL_NUMBER foo.pfx (replace the password and the serial number with their actual values)
You should now have a valid store pfx.
Yet another option for even more advanced generation
Use OpenSSL. Pretty sure it can do all the above and more, but I haven't tried it personally so you'll have to figure it out - and hopefully share here once you do!
How can I find out where my OpenSSL installation is looking for installed (trusted) certificates?
It is sometimes /etc/ssl/cert, but I have a new system and it is not working with this path.
The default path where certificates are looked up might be different on each platform. You can lookup your system configuration using the following command:
$ openssl version -d
OPENSSLDIR: "/etc/pki/tls"
This C snippet, compiled against OpenSSL, will tell you:
#include <stdlib.h>
#include <stdio.h>
#include <openssl/x509.h>
int main()
{
const char *dir;
dir = getenv(X509_get_default_cert_dir_env());
if (!dir)
dir = X509_get_default_cert_dir();
puts(dir);
return 0;
}
The path you are looking for is the "Directory for OpenSSL files". As #tnbt answered, openssl version -d (or -a) gives you the path to this directory. OpenSSL looks here for a file named cert.pem and a subdirectory certs/. Certificates it finds there are treated as trusted by openssl s_client and openssl verify (source: the article, What certificate authorities does OpenSSL recognize?).
% openssl version -d
OPENSSLDIR: "/opt/local/etc/openssl"
% ls -l /opt/local/etc/openssl/cert*
lrwxr-xr-x 1 root admin 40 29 Nov 02:05 /opt/local/etc/openssl/cert.pem -> /opt/local/share/curl/curl-ca-bundle.crt
% head -10 /opt/local/etc/openssl/cert.pem
##
## Bundle of CA Root Certificates
##
## Certificate data from Mozilla as of: Fri Nov 24 08:00:26 2017 GMT
##
## This is a bundle of X.509 certificates of public Certificate Authorities
## (CA). These were automatically extracted from Mozilla's root certificates
## file (certdata.txt). This file can be found in the mozilla source tree:
## https://hg.mozilla.org/releases/mozilla-release/raw-file/default/security/nss/lib/ckfw/builtins/certdata.txt
##
...[rest of file omitted]...
It turns out that the installer which installed OpenSSL on my system also installed cert.pem as a symlink to a bundle of Certificate Authority certificates from the tool cUrl . Those in turn came from Mozilla.
You might have nothing installed in this file or directory, or you might have a different set of certificates. This will affect which server certificates OpenSSL verifies.
OpenSSL commands like s_client support, I think since version 1.1, options -no-CAfile and -no-CApath. These let you ignore the certificates in this file and directory respectively, for the duration of one command. (I can't reproduce this because I am still using version 1.0.2, and it lacks those options.)
How can I find out, where my openssl installed is looking for installed certificates (trusted)?
You can't. OpenSSL trusts nothing by default, and it does not go looking for certs. You have to instruct it what to trust. There's even a FAQ topic covering it: Why does <SSL program> fail with a certificate verify error?:
This problem is usually indicated by log messages saying something
like "unable to get local issuer certificate" or "self signed
certificate". When a certificate is verified its root CA must be
"trusted" by OpenSSL this typically means that the CA certificate must
be placed in a directory or file and the relevant program configured
to read it. The OpenSSL program 'verify' behaves in a similar way and
issues similar error messages: check the verify(1) program manual page
for more information.
Caf's answer is kind of correct, but OpenSSL does not use it and there's nothing there...
$ grep -R X509_get_default_cert_dir *
...
crypto/x509/x509_def.c:const char *X509_get_default_cert_dir(void)
...
In the above, notice it does not hit on anything in the apps/ directory. apps/ is where all the OpenSSL samples and utilities are, like openssl req, openssl rsa, openssl dsa, openssl x509, openssl sign, openssl verify, etc.
Then:
$ cat crypto/x509/x509_def.c
...
const char *X509_get_default_cert_dir(void)
{ return(X509_CERT_DIR); }
...
$ grep -R X509_CERT_DIR *
crypto/cryptlib.h:#define X509_CERT_DIR OPENSSLDIR "/certs"
And finally:
$ ls /usr/local/ssl/certs/
$
Like I said, its not used and there's nothing there.