Using SSL Certificates with the Apache Tomcat Web Server
Creating PKCS12 Files
PKCS #12 is a format for storing multiple cryptography objects in a single archive file. You can store arbitrarily complex objects within a PKCS #12 archive, but the most common use is to store a single private key and its certificate chain. Create a PKCS12 file from PEM files:
openssl pkcs12 -export -in ssl_cert.pem -inkey key.pem -certfile bundle.crt -name "*.example.com" -out example.com.p12Depending on the product you’re working with, the documentation may call for a .pfx file instead of a .p12 file. PFX is an older format that was a predecessor to PKCS #12. In most modern systems, A PFX FILE AND A P12 FILE ARE EXACTLY THE SAME THING! You can just change the extension if needed and that will generally work. For example, the docs for ESET Security Management Center call for a pfx file, but a PKCS12 file will work just fine.
Node.js: Connecting to MySQL on a socket with Sequelize
According to its official description, “Sequelize is a promise-based Node.js ORM for Postgres, MySQL, MariaDB, SQLite and Microsoft SQL Server.” Sequelize is widely used in Node.js web applications to abstract the database layer. I recently found a “corner case” for Sequelize which is possible to accomplish, but is not well documented anywhere on the web. I need to use Sequelize to connect to a MySQL server via a UNIX socket. I’m developing some plugins for Confluence that use the atlassian-connect-express toolkit, which has a datastore that wraps Sequelize. The way Atlassian has chosen to wrap Sequelize is rather unfortunate, probably because they are trying to maintain backwards compatibility with JugglingDB. Essentially, the Atlassian Connect Express only looks at the URL, and ignores any option passed to Sequelize. Therefore, you have to pass everything you need via the URL, and this is where it’s tricky. Here’s the form of the URL that you need to connect to MySQL via a UNIX socket with Sequelize:
Use an SSL/TLS Certificate with ESET Security Management Center Appliance
ESET Security Management Center (ESMC) is the replacement for the ESET Remote Administrator (ERA) Server. You can install ESMC as a “virtual appliance” which will run on hosts such as VMWare or Linux/KVM/QEMU. Under the hood, this appliance is a CentOS 7 server running the Apache Tomcat web server. ESMC is implemented as a Java application that runs as a systemd service. In my experience, ESET is a solid security product, and the free ERA/ESMC provides some rudimentary endpoint management capabilities. Unfortunately, everything about ESET is confusing, from the naming of their products to their documentation. The documentation is thorough…it’s just hard to find what you’re looking for, which is usually in multiple overlapping documents that each contain part of the puzzle.
Testing Access to Google Bigtable
This is a minimal PHP script that’s useful for verifying connectivity and permissions to read data from a Google Bigtable instance. Unlike some of the sparse examples in Google’s PHP SDK, this script will work for any table, and you don’t need to know anything about the structure of the table. This script tests the critical elements that need to work together to enable Bigtable access:
Credential file GRPC extension for PHP Protobuf extension for PHP Scopes enabled on Compute Engine instances
curl or libcurl: SSL certificate problem: unable to get local issuer certificate
curl, or an application that uses libcurl, may have a problem with an SSL certificate that works fine when using a web browser to access the same URL. Typical error output from curl looks like this:
$ curl -v https://my-subdomain.mysecuresite.com
Trying xxx.xxx.xxx.xxx:443…
TCP_NODELAY set
Connected to my-subdomain.mysecuresite.com (xxx.xxx.xxx.xxx) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (OUT), TLS alert, unknown CA (560):
SSL certificate problem: unable to get local issuer certificate
Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.Troubleshooting Strategy
- A good starting point for any SSL error on a public-facing URL is to analyze the URL at SSL Labs.
- Does the error happen for all certificates issued by a specific Certificate Authority (CA)? If so, the system running curl may need to have a root certificate for that CA added or updated in its certificate repository. That’s a relatively rare problem, but might occur if the system running curl is very old. There’s a comprehensive thread about this issue on Stack Overflow.
- If the error only happens for one specific site, it’s likely that the site is missing an intermediate certificate. The command to diagnose this issue is also found in that Stack Overflow thread:
openssl s_client -connect myhost.com:443 -servername myhost.com -showcertsThe output should show a series of certificates, starting with the site certificate, and ending with the root certificate for the Certification Authority. If this chain only shows the site certificate, that’s the problem.
Monitoring a switch or router port via SNMP
Most business-class switches and routers support monitoring via SNMP. The main barrier to implementing SNMP monitoring is that so many parameters can be monitored, and it can be very hard to isolate the most important parameters. This example shows how to monitor the status of a specific port. Note that the term “port” includes link aggregation groups (LAGs) or other logical groups of ports like VLANs.
Use Case
A top-of-rack switch has several important link aggregation groups (LAGs). For example, one LAG has connections to two identical routers in a VRRP cluster. Other LAGs provide redundant network paths to independent NICs on the same server. I want to be alerted if the port status changes on any critical LAG. The ISP delivers Internet to a single port on the switch, which I also want to monitor.
openssl unable to read/load/import SSL private key from GoDaddy
openssl is the standard open-source, command-line tool for manipulating SSL/TLS certificates on Linux, MacOS, and other UNIX-like systems. I recently ran into an interesting problem using openssl to convert a private key obtained from GoDaddy. Someone else used GoDaddy’s “wizard” interface to generate a certificate signing request (CSR) and private key, and saved the files on their Windows workstation. They purchased an SSL cert from GoDaddy, and shared all the files with me for installation on servers. GoDaddy saved the private key in the newer PKCS #8 format (pkcs8), and one system required the key in the older PKCS #1 (pkcs1) format. It’s easy to tell the difference.
Nginx default user changed in RedHat/CentOS package nginx-1.16.1-1.el7
The latest Nginx rpm (nginx-1.16.1-1.el7) from EPEL for CentOS/Redhat is a fairly major update, from version 1.12 to 1.16, and includes some very important fixes to address multiple CVEs. There is another small but critical change in the latest RPM that isn’t mentioned in the bug report. RedHat had configured nginx to run as user “apache” in past releases, but in the EPEL release on 19 October 2019, the configuration was changed to run as user “nginx”. If you ran “yum upgrade” recently (which you really need to do on a regular basis) on any system with nginx installed, you probably have a system that is affected.
mount.cifs error 13 after update (CentOS/RedHat Linux 7.6)

PERMISSION DENIED
PERMISSION DENIED (Photo by Hidde van Esch on Unsplash)
If you recently updated your RedHat or CentOS 7.6 system, you may suddenly start getting “Permission Denied” errors when attempting to mount SMB shares via CIFS. Typical error messages in syslog look like this:
kernel: Status code returned 0xc000006d STATUS_LOGON_FAILURE
kernel: CIFS VFS: Send error in SessSetup = -13
kernel: CIFS VFS: cifs_mount failed w/return code = -13Configuration that triggered the problem
Synology NAS with latest operating system shares a volume via SMBCentOS 7 Linux server mounts SMB share using a local username and password (NOT domain credentials)cifs-utils version 6.2 installed in May of 2019 (this by itself worked fine)libsmbclient just updated to 4.9.1-6libmount just updated to 2.23.2-61CIFS mount options: vers=3.0,credentials=/root/credentials.txt,sec=ntlmsspi* File /root/credentials.txt contained a username and password that are LOCAL to the SMB server