On Linux using IBM MQ V9.2.0 I have seen the following error
EXPLANATION:
The SSL key repository cannot be used because MQ cannot obtain a password to access it. Reasons giving rise to this error include:
(a) the key database file and password stash file are not present in the location configured for the key repository,
(b) the key database file exists in the correct place but that no password stash file has been created for it,
(c) the files are present in the correct place but the userid under which MQ is running does not have permission to read them,
(d) one or both of the files are corrupt.
I did all the things mentioned in IBM docs but I am not able to resolve.
The SSLKEYR value is /var/mqm/qmgrs/QMGRname/ssl/key
-rwxrwxr-x. 1 mqm mqm 80 Apr 21 14:31 key.rdb
-rwxrwxr-x. 1 mqm mqm 193 Apr 21 14:32 key.sth
-rwxrwxr-x. 1 mqm mqm 15K Apr 21 14:44 key.kdb
(mq:9.2.0.0)root#22955896bc26:/var/mqm/qmgrs/qmgr/ssl# runmqakm -cert -list -db /var/mqm/qmgrs/qmgr/ssl/key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! "mns non-prod root ca"
! "mns plc sub ca cate"
- ibmwebspheremqqmgr
(mq:9.2.0.0)root#22955896bc26:/var/mqm/qmgrs/qmgr/ssl# runmqakm -cert -list -db /var/mqm/qmgrs/qmgr/ssl/key.kdb -stashed
CTGSK3026W The key file "/var/mqm/qmgrs/qmgr/ssl/key.kdb" does not exist or cannot be read.
CTGSK2101W The key database does not exist.
-Command usage-
-list Required <all | personal | ca>
-db | -crypto Required
-tokenlabel Required if -crypto present
-pw | -stashed Optional
-type Optional <cms | kdb | pkcs12 | p12>
-secondarydb Optional if -crypto present
-secondarydbpw Optional if -secondarydb present
-secondarydbtype Optional if -secondarydb present
-expiry Optional
-rfc3339 Optional
-v Optional
$ runmqakm -cert -list -db /var/mqm/qmgrs/qmgr/ssl/key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! "mns non-prod root ca"
! "mns plc sub ca cate"
- ibmwebspheremqqmgr
1 : DIS QMGR SSLKEYR CERTLABL
AMQ8408I: Display Queue Manager details.
QMNAME(qmgr) CERTLABL(ibmwebspheremqqmgr)
SSLKEYR(/VAR/MQM/QMGRS/qmgr/SSL/KEY)
1 : DIS QMGR SSLKEYR CERTLABL
AMQ8408I: Display Queue Manager details.
QMNAME(qmgr) CERTLABL(ibmwebspheremqqmgr)
SSLKEYR(/var/mqm/qmgrs/qmgr/ssl/key)
-rwxrwxr-x. 1 mqm mqm 15088 Apr 28 17:18 /var/mqm/qmgrs/AZMQGW02/ssl/key.kdb
-rwxrwxr-x. 1 mqm mqm 80 Apr 28 17:18 /var/mqm/qmgrs/AZMQGW02/ssl/key.rdb
-rwxrwxr-x. 1 mqm mqm 193 Apr 28 17:19 /var/mqm/qmgrs/AZMQGW02/ssl/key.sth
(mq:9.2.0.0)root#22955896bc26:/var/mqm/qmgrs/AZMQGW02/ssl# su - mqm
No directory, logging in with HOME=/
$ getfacl /var/mqm/qmgrs/AZMQGW02/ssl/key.*
-su: 1: getfacl: not found
Unix is case sensitive, /VAR/MQM/QMGRS/AZMQGW02/SSL/KEY is not the same as /var/mqm/qmgrs/AZMQGW02/ssl/key.
To fix the issue run the following:
printf "ALTER QMGR SSLKEYR('/var/mqm/qmgrs/AZMQGW02/ssl/key')\nREFRESH SECURITY TYPE(SSL)\n" | runmqsc AZMQGW02
Note that with MQSC commands if you do not surround a string with single quotes it will be folded to UPPER CASE.
Related
I'm trying to connect to MariaDB with Google App Script.
I've been following this post, and these instructions and used this advice to get the certs setup.
const server = 'x.x.x.x'; //not my actual ip
const port = 3306;
const dbName = 'myDbName';
const username = 'googleusername';
const password = 'hunter2';
const url = 'jdbc:mysql://'+server+':'+port+'/'+dbName+'?useSSL=true';
const serverSslCertificate = '-----BEGIN CERTIFICATE-----\n'+
'zxcv1231223123'+
.... etc ....
'112223334'+'\n'+
'-----END CERTIFICATE-----';
const clientSslCertificate = '-----BEGIN CERTIFICATE-----\n
'+ 'zxcv1231223123'+
.... etc ....
'112223334'+'\n'+
'-----END CERTIFICATE-----';
const clientSslKey ='-----BEGIN RSA PRIVATE KEY-----\n
'+ 'zxcv1231223123'+
.... etc ....
'112223334'+'\n'+
'-----END RSA PRIVATE KEY-----';
var connParams = {
user: username,
password: password,
_serverSslCertificate: serverSslCertificate,
_clientSslCertificate: clientSslCertificate,
_clientSslKey: clientSslKey,
};
When I try to connect, it fails and in MariaDB I can see in the mysql error logs:
2022-10-18 23:01:50 18 [Warning] Access denied for user 'googleusername'#'y.y.y.y' (using password: YES)
And in Apps Script I see
Exception: Failed to establish a database connection. Check connection string, username and password.
If I do:
MariaDB [bitnami_wordpress]> SHOW GLOBAL VARIABLES LIKE '%ssl%' \G
*************************** 1. row ***************************
Variable_name: have_openssl
Value: YES
*************************** 2. row ***************************
Variable_name: have_ssl
Value: DISABLED
*************************** 3. row ***************************
Variable_name: ssl_ca
Value: /opt/bitnami/mariadb/certs/ca.pem
*************************** 4. row ***************************
Variable_name: ssl_capath
Value:
*************************** 5. row ***************************
Variable_name: ssl_cert
Value: /opt/bitnami/mariadb/certs/server-cert.pem
*************************** 6. row ***************************
Variable_name: ssl_cipher
Value:
*************************** 7. row ***************************
Variable_name: ssl_crl
Value:
*************************** 8. row ***************************
Variable_name: ssl_crlpath
Value:
*************************** 9. row ***************************
Variable_name: ssl_key
Value: /opt/bitnami/mariadb/certs/server-key.pem
Found this in the MariaDB startup log:
2022-10-18 23:32:19 0 [Warning] Failed to setup SSL
2022-10-18 23:32:19 0 [Warning] SSL error: SSL_CTX_set_default_verify_paths failed
2022-10-18 23:32:19 0 [Warning] SSL error: error:02001002:system library:fopen:No such file or directory
2022-10-18 23:32:19 0 [Warning] SSL error: error:2006D080:BIO routines:BIO_new_file:no such file
2022-10-18 23:32:19 0 [Warning] SSL error: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib
I took a look at the have_ssl = disabled thing, and found this.
bitnami#ip-172-26-11-184:~/stack/mariadb/conf/certs$ ls -lah
total 40K
drwxr-xr-x 2 bitnami root 4.0K Oct 9 04:17 .
drwxrwxr-x 4 root root 4.0K Oct 18 22:10 ..
-rw-r--r-- 1 bitnami root 1.7K Oct 9 04:16 ca-key.pem
-rw-r--r-- 1 bitnami root 1.4K Oct 9 04:17 ca.pem
-rw-r--r-- 1 bitnami root 1.3K Oct 9 04:17 client-cert.pem
-rw------- 1 bitnami root 1.7K Oct 9 04:17 client-key.pem
-rw-r--r-- 1 bitnami root 1.1K Oct 9 04:17 client-req.pem
-rw-r--r-- 1 bitnami root 1.3K Oct 9 04:17 server-cert.pem
-rw------- 1 bitnami root 1.7K Oct 9 04:17 server-key.pem
-rw-r--r-- 1 bitnami root 1.1K Oct 9 04:17 server-req.pem
bitnami#ip-172-26-11-184:~/stack/mariadb/conf$ ls -lah
total 24K
drwxrwxr-x 4 root root 4.0K Oct 18 22:10 .
drwxr-xr-x 12 root root 4.0K Apr 14 2022 ..
drwxrwxr-x 3 root root 4.0K Sep 5 11:52 bitnami
drwxr-xr-x 2 bitnami root 4.0K Oct 9 04:17 certs
-rw-rw-r-- 1 bitnami root 1.1K Oct 18 22:10 my.cnf
-rw-r--r-- 1 root root 1002 Oct 9 04:16 run.sh
Amongst other things in my my.cnf:
[mysqld]
skip_name_resolve
explicit_defaults_for_timestamp
basedir=/opt/bitnami/mariadb
port=3306
tmpdir=/opt/bitnami/mariadb/tmp
socket=/opt/bitnami/mariadb/tmp/mysql.sock
pid_file=/opt/bitnami/mariadb/tmp/mysqld.pid
max_allowed_packet=16M
bind_address=0.0.0.0
log_error=/opt/bitnami/mariadb/logs/mysqld.log
slow_query_log=0
slow_query_log_file=/opt/bitnami/mariadb/logs/mysqld.log
long_query_time=10.0
character_set_server=utf8
collation_server=utf8_general_ci
plugin_dir=/opt/bitnami/mariadb/lib/plugin
ssl_ca=/opt/bitnami/mariadb/certs/ca.pem
ssl_cert=/opt/bitnami/mariadb/certs/server-cert.pem
ssl_key=/opt/bitnami/mariadb/certs/server-key.pem
require_secure_transport=ON
Does anyone have any ideas of what to try next and why it's not working?
I got to the bottom of it.
Lessons learnt:
If
MariaDB [bitnami_wordpress]> SHOW GLOBAL VARIABLES LIKE '%ssl%' \G
shows
Variable_name: have_ssl
Value: DISABLED
Then your server side SSL is not enabled.
Check the MySQL log on reload/restart
[Warning] SSL error: error:02001002:system library:fopen:No such file or directory 2022-10-18 23:32:19 0
This kind of thing is a hint - in my case that I'd listed the paths wrong in the config file
The certificates that are needed on the client side are:
The Certificate Authority (ca.pem)
Client Cert
Client Key
In my case, I had the server cert, rather than the CA certificate.
It may be worth trying to connect with the certificates from a commandline client, but whatever "--ssl-verify-server-cert " does, it isn't what App Script does when it tries to connect.
Thanks #danblack for the pointers and encouragement.
I am getting this error in my tomcat catalina.out log:
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
when trying to access this remote URL: https://remote-hostname-fqdn-here:8443. This works fine when the same call is made locally.
I have the certificate imported into the keystore, i.e. I see the following when I list the certs content with keytool:
$ /opt/jdk1.7.0_75/bin/keytool -list -v -keystore /opt/apache-tomcat/conf/ssl/cacerts | grep icr
Alias name: remote-hostname-fqdn-here
Creation date: Jan 4, 2018
Entry type: trustedCertEntry
Owner: CN=remote-hostname-fqdn-here, O="Org-name-removed", L=Place-removed, ST=State-removed, C=US
Issuer: CN=remote-hostname-fqdn-here, O="Org-name-removed", L=Place-removed, ST=State-removed, C=US
Serial number: serial-number-removed
Valid from: Thu Jan 04 13:22:32 CST 2018 until: Sun Jan 02 13:22:32 CST 2028
Certificate fingerprints:
MD5: md5sum-value-removed
SHA1: sha1-value-removed
SHA256: sha256-value-removed
Signature algorithm name: SHA1withRSA
Version: 1
Note that I have tomcat instances in two environments, both running Java jdk1.7.0_75 and Tomcat 7.0.90, and the same SSL connector configuration. Strangely enough, this error only happens on one of them, even though we've tried the same action to clear the application cache to trigger the error on both.
While I do have a wildcard cert (different from the cert mentioned here) configured in server.xml on all the servers, I can see it logical that I'd have to import that cert into the keystore. However, I haven't imported it on either environment, so I'm at a loss as to why I'm only getting this error in one environment. Note that other than this functionality of clearing a remote server's application cache, all other aspects of SSL seem to be working fine.
Importing the wildcard cert that covered the same domain as the current ones for each server solved the problem. Still don’t know why I wasn’t able to recreate the problem in the other environment. While the .war and .jar files were different, I was told the portion of the code for the problem here is the same.
I am trying to configure Linux machine authentication with Google secure LDAP, adding the steps below that I have done
Added the LDAP client with below permission:
Access permission: Entire Domain
Read user information: Entire Domain
Read group information: ON
Installed SSSd in my Ubuntu box(which is running in Azure)
sudo apt install -y sssd sssd-tools
My sssd.conf file
[sssd]
debug_level = 7
services = nss, pam
domains = mydomain.com
[pam]
debug_level = 7
[nss]
debug_level = 7
[domain/mydomain.com]
debug_level = 7
cache_credentials = true
ldap_id_use_start_tls = true
ldap_tls_cacertdir = /home/ubuntu/ssl_Linux
ldap_tls_cacert = /home/ubuntu/ssl_Linux/gldap.crt
ldap_tls_cert = /home/ubuntu/ssl_Linux/gldap.crt
ldap_tls_key = /home/ubuntu/ssl_Linux/gldap.key
ldap_uri = ldaps://ldap.google.com:636
ldap_search_base = ou=Users,dc=mydomain,dc=com
ldap_group_name = uniqueMember
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_user_uuid = entryUUID
ldap_groups_use_matching_rule_in_chain = true
ldap_initgroups_use_matching_rule_in_chain = true
enumerate = false
Here I'm able to start the SSSD service bt getting the below error
Nov 15 09:14:54 myserver systemd[1]: Started System Security Services Daemon.
Nov 15 09:14:55 myserver sssd[be[67530]: Could not start TLS encryption. (unknown error code)
Nov 15 09:16:11 myserver sssd[be[67530]: Could not start TLS encryption. (unknown error code)
Nov 15 09:16:11 myserver sssd[be[67530]: Backend is offline
Nov 15 09:17:19 myserver sssd[be[67530]: Could not start TLS encryption. (unknown error code)
Nov 15 09:19:48 myserver sssd[be[67530]: Could not start TLS encryption. (unknown error code)
Nov 15 09:24:02 myserver sssd[be[67530]: Could not start TLS encryption. (unknown error code)
FYI: I'm able to successfully authenticate with the google secure LDAP using below command
LDAPTLS_CERT=mycrt.crt LDAPTLS_KEY=mykey.key ldapsearch -H ldaps://ldap.google.com:636 -b "ou=Users,dc=mydomain,dc=com" -D "my.user#mydomain.com" "(uid=my.user)" -W
Refrance: https://helpcenter.itopia.com/en/articles/2394004-configuring-google-cloud-identity-ldap-on-ubuntu-16-04-for-user-logins
Please help me on this,
Thanks :)
I had same issue.
adding ldap_tls_cipher_suite = NORMAL:!VERS-TLS1.3 to sssd.conf file worked for me. I am on Ubuntu 20.04.5 LTS
I had tried the same document with the new Virtual-Machine, It works fine for me.
Just need to make sure after configuring google LDAP client in http://admin.google.com/ portal may take up to 24 hours to take effect.
Thanks
I did a "renew Cert" on one of my Enterprise subCAs, and it's totally messed up my results on Enterprise PKI in MMC. In the Certificate Authority snapin, there are now two certs (Certificate #0 and #1). The AIA (ldap) is showing "Unable to Download", with the "original CN=". The CDP (ldap) location has a (1) on it, as does the DeltaCRL. Every time I renew the revocation, it makes both the original cert's crl and a (1). The CDP/DeltaCRL (http) also both show "unable to download", even though the files exist in the directory. The only AIA location that shows OK is the http location.
I need to get rid of the old CA cert (the #0), I'll re-push the new one out via a GPO once this all is resolved. I tried to remove the AIA via ADSIEdit, and then republish it via "certutil -dspublish" but that gives me a 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER) error. Trying to connect to the Configuration of the specific CA via ADSIEdit says "server is not operational". In ADSIEdit CN=CDP there are multiple entries, the normal "CA", a "CA-1", and a "CA-1(1)".
This is in our "Test" environment (luckily), but I need to get a proper process sorted out as I need to do this in two other forests. I'm actually tempted to just totally rebuild a new CA in the other zones instead of fighting with all of this.
All I'm trying to do is re-issue a subCA's cert, and get it to work correctly and report healthy in Enterprise PKI!
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\OMNI-
TST-CERTAUTH-01-CA-1\CRLPublicationURLs:
CRLPublicationURLs REG_MULTI_SZ =
0: 65:C:\windows\system32\CertSrv\CertEnroll\%3%8%9.crl
CSURL_SERVERPUBLISH -- 1
CSURL_SERVERPUBLISHDELTA -- 40 (64)
1: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
CSURL_SERVERPUBLISH -- 1
CSURL_ADDTOCERTCDP -- 2
CSURL_ADDTOFRESHESTCRL -- 4
CSURL_ADDTOCRLCDP -- 8
CSURL_SERVERPUBLISHDELTA -- 40 (64)
2: 134:http://pki.omni.phish/CertEnroll/%3%4%9.crl
CSURL_ADDTOCERTCDP -- 2
CSURL_ADDTOFRESHESTCRL -- 4
CSURL_ADDTOIDP -- 80 (128)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\OMNI-
TST-CERTAUTH-01-CA-1\CACertPublicationURLs:
CACertPublicationURLs REG_MULTI_SZ =
0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
CSURL_SERVERPUBLISH -- 1
1: 3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11
CSURL_SERVERPUBLISH -- 1
CSURL_ADDTOCERTCDP -- 2
2: 32:http://%1/ocsp
CSURL_ADDTOCERTOCSP -- 20 (32)
3: 32:http://pki.omni.phish/oscp
CSURL_ADDTOCERTOCSP -- 20 (32)
4: 2:http://pki.omni.phish/CertEnroll/%3.crt
CSURL_ADDTOCERTCDP -- 2
CRLPublicationURLs
1st, you're publish to the local disk (C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl) but nowhere else. Now you may have a manual process in place to upload this CRL to the CDP, in which case this is fine. Otherwise, you need to add another url (for example 65:file://\\[server]\[share]\%3%8%9.crl, where [server] is your CDP and [share] is a share for the directory containing your CRLs) so that new CRLs are automatically published to the CDP by the CA.
2nd, you are using a CDP of http://pki.omni.phish//CertEnroll/%3%4%9.crl. The %4 should be %8.
When you renew a CA certificate, you need the original CA certificate and CRL to still be available so that all end-entities that were previously issued certificates still work. Microsoft CAs do this by appending a (1) to the CRL name, just before the .crl extension for the 1st replacement certificate (Certificate #1 in the MMC) and (2) for the next renewal and so on. This is configured by the %8 in the CRLPublicationURLs registry key.
CAPublicationURLs
You are adding the URL to the CA certificate as http://pki.omni.phish/CertEnroll/%3.crt. You need to add a %4 after the %3.
The %4 does a similar job to what %8 does for CRLs. Without it, the CA certificate name remains the same.
There are three different ways you can fix these:
You can use the MMC - under Extensions on the CA Properties dialog. However, it's really clumsy to operate.
You can use the certutil -setreg command, but you have to overwrite all of the settings - you can't edit one line.
You can edit the registry directly at HKLM\SYSTEM\CurrentControlSet\Services\CertSrv\Configuration\[CA Name]
I find the latter is the simplest.
May I suggest some PKI and Microsoft ADCS revision before you touch production? :-)
I'm having trouble getting our system up and running using HTTPS.
I have created a keyfile from our wildcard certificate and placed the keyfile in our ./conf directory:
473 zbeckman:glimpulse-server$ ll conf
total 72
drwxr-xr-x 9 zbeckman staff 306 Sep 7 09:26 ./
drwxr-xr-x 22 zbeckman staff 748 Sep 7 09:32 ../
-rwxr-xr-x 1 zbeckman staff 1213 Sep 7 09:26 application.conf*
-rw-r--r-- 1 zbeckman staff 1374 Sep 7 08:49 glimpulse.keystore
-rw-r--r-- 1 zbeckman staff 1439 Aug 9 15:58 logback.xml
-rwxr-xr-x 1 zbeckman staff 5206 Aug 8 15:36 routes*
-rw-r--r-- 1 zbeckman staff 575 Apr 29 18:55 ws.conf
474 zbeckman:glimpulse-server$
And I have added the following to our ./conf/application.conf file, as per instructions in the Play Configuring HTTPS page:
play.server.https.keyStore.path = "./conf/glimpulse.keystore"
play.server.https.keyStore.password = "xxxxxxxxxxxxx"
And finally, I'm using -Dhttp.port=disabled -Dhttps.port=9000 to try and start the server, but it refuses to start.
Here are the results. Note the last line of output:
472 zbeckman:glimpulse-server$ ./activator start -Dhttp.port=disabled -Dhttps.port=9000
[info] Loading project definition from /Users/zbeckman/Projects/Glimpulse/Server/project/glimpulse-server/project
[info] Set current project to Glimpulse (in build file:/Users/zbeckman/Projects/Glimpulse/Server/project/glimpulse-server/)
[warn] The start command is deprecated, and will be removed in a future version of Play.
[warn] To run Play in production mode, run 'stage' instead, and then execute the generated start script in target/universal/stage/bin.
[warn] To test your application using production mode, run 'testProd' instead.
[info] Wrote /Users/zbeckman/Projects/Glimpulse/Server/project/glimpulse-server/target/scala-2.11/glimpulse_2.11-1.0-SNAPSHOT.pom
(Starting server. Type Ctrl+D to exit logs, the server will remain in background)
Must provide either an HTTP or HTTPS port
473 zbeckman:glimpulse-server$
As far as the keystore goes, I used the Java keytool to generate the store, based on our wildcard domain certificate:
keytool -import -alias tomcat -keystore glimpulse.keystore -trustcacerts -file star_glimpulse_com.crt
That seemed to go just fine, and the keystore was generated without any errors or warnings.
You could try to run it like this:
./activator "start -Dhttp.port=disabled -Dhttps.port=9000"
The quotes may be required to make sure the parameters get passed to the start command the right way.
Simply add this to your application.conf:
https {
# The HTTPS port of the server.
port = 9001
}
and your app will listen on port 9001