All posts by Pistolfly

Software Engineer in Tokyo, Japan

Certificate without subjectAltName causes NET::ERR_CERT_COMMON_NAME_INVALID error on Chrome

When I visited a site that uses a self-signed SSL certificate for development environment with Chrome, "Your connection is not private. NET::ERR_CERT_COMMON_NAME_INVALID" error occurred.

Although I use a self-signed certificate, I installed it for the clients and trusted it. (Keychain Access on Mac and Certificate Manager on Windows.)
The CN(Common Name) also matches the host name being accessed.

There is no problem with browsers other than Chrome.
Even Chrome could access without problems, but suddenly it got an error.

There is "[missing_subjectAltName]" in the error, so I thought the certificate without subjectAltName caused the error.

Cause

For Chrome 58 and later, only the subjectAlternativeName extension, not commonName, is used to match the domain name and site certificate.

https://support.google.com/chrome/a/answer/7391219?hl=en

Workaround

Create self-signed certificate with subjectAltName extension

Copy openssl.cnf and set subjectAltName, use it on creating certificate.

  1. Copy openssl.cnf(Below is example on Red Hat family. Change the path to openssl.cnf for other platforms.)
    $ cp /etc/pki/tls/openssl.cnf my-server.example.com.cnf
    
  2. x509_extensions in [ req ] section is v3_ca. So it seems I should add subjectAltName in [ v3_ca ] section.
    $ vi my-server.example.com.cnf
    
    [ req ]
    ...
    x509_extensions = v3_ca # The extentions to add to the self signed cert
    ...
    

    Add subjectAltName in [ v3_ca ] section.

    [ v3_ca ]
    ...
    subjectAltName=DNS.1:my-server.example.com
    ...
    

    You can also set multiple subjectAltNames.

    subjectAltName=DNS.1:my-server.example.com,DNS.2:my-server2.example.com
    

    See `man 5 x509v3_config` for detail.

  3. Create private key
    $ openssl genrsa -out my-server.example.com.key 2048
    
  4. Create certificate(Specify your cnf file for the -config option
    $ openssl req -new -x509 -days 36500 -sha256 -config my-server.example.com.cnf -key my-server.example.com.key -out my-server.example.com.crt
    

Installing scl devtoolset on CentOS6

When trying to build nodejs (v6.9.1) on CentOS6, `make` got an error.
It requires gcc and g++ 4.8 or later, but CentOS6's gcc is 4.4.7.

node-v6.9.1/BUILDING.md

Prerequisites:

* `gcc` and `g++` 4.8 or newer, or
* `clang` and `clang++` 3.4 or newer
* Python 2.6 or 2.7
* GNU Make 3.81 or newer

So I decided to install gcc and g++ 4.8 or later with scl.

$ sudo yum install centos-release-scl
$ sudo yum install scl-utils
$ sudo yum install devtoolset-4-gcc devtoolset-4-gcc-c++ devtoolset-4-binutils
$ scl enable devtoolset-4 bash
$ gcc --version
gcc (GCC) 5.2.1 20150902 (Red Hat 5.2.1-2)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

There are devtoolset-3 and devtoolset-4. I installed devtoolset-4.
I installed only gcc, g++ and binutils necessary for building nodejs, because it is massive when installing all with devtoolset-4.

$ scl enable < collection1> [< collection1> ...] bash

This makes bash start with the environment where the installed collection can be used.

To enable software collections for users after reboot, create under /etc/profile.d with the following content.

$ cat /etc/profile.d/enabledevtoolset-4.sh
#!/bin/bash
source scl_source enable devtoolset-4

https://access.redhat.com/solutions/527703

Caution

When devtoolset-4 is enabled, sudo is sometimes broken such as `sudo -i` results in error.

$ sudo -i
[sudo] password for foo:
/var/tmp/sclXXXXXX: line 8: -i: command not found

https://bugzilla.redhat.com/show_bug.cgi?id=1319936

In such cases, you can use `/usr/bin/sudo` explicitly.

Error in yum update on CentOS 6.7 `http://mirror.centos.org/centos/6/SCL/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"`

CentOS release 6.7 (Final)

yum update fails on the error below.

http://mirror.centos.org/centos/6/SCL/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: scl. Please verify its path and try again

Workaround

$ sudo yum remove centos-release-SCL
$ sudo yum update # Update to CentOS 6.8
$ sudo yum install centos-release-scl
$ sudo yum update

Source: 0010925: Yum update fails on a 404 returned from http://mirror.centos.org/centos/6/SCL/x86_64/repodata/repomd.xml - CentOS Bug Tracker

Paste text into Android emulator or device

$ adb shell input text 'text to paste'
  • For convenience, add the path to adb to PATH environment variable.
    You can find the path to adb in Android Studio [Project Sturcture] > [SDK Location]
  • If multiple devices are connected, specify the serial number of the device by -s option.
    The serial number of the device can be found like below.

    $ adb devices
    
  • Althogh I enclose the text to paste with single quotation marks ('), metacharacters or $0, $1... are extracted by the shell. You should escape them with backslash (\).

Example:

$ adb -s emulator-5554 shell input text 'text to paste'

passenger-config and passenger-status result in an error on CentOS7

passenger-config and passenger-status result in an error on CentOS7.

  • CentOS Linux release 7.2.1511 (Core)
  • Apache/2.4.6 (CentOS)
  • Phusion Passenger 5.0.23 (Installed by `passenger-install-apache2-module`)
$ passenger-config restart-app
*** ERROR: Phusion Passenger doesn't seem to be running. If you are sure that it
is running, then the causes of this problem could be one of:

 1. You customized the instance registry directory using Apache's
    PassengerInstanceRegistryDir option, Nginx's
    passenger_instance_registry_dir option, or Phusion Passenger Standalone's
    --instance-registry-dir command line argument. If so, please set the
    environment variable PASSENGER_INSTANCE_REGISTRY_DIR to that directory
    and run this command again.
 2. The instance directory has been removed by an operating system background
    service. Please set a different instance registry directory using Apache's
    PassengerInstanceRegistryDir option, Nginx's passenger_instance_registry_dir
    option, or Phusion Passenger Standalone's --instance-registry-dir command
    line argument.

Reason

Passenger could not find instance registry directory (PassengerInstanceRegistryDir on Apache, passenger_instance_registry_dir on Nginx).

If instance registry directory is not explicitly specified, default value /tmp is used.
So instance registry dir is made in /tmp. But because Systemd PrivateTmp option is enabled on httpd (default), instance registry dir is created in httpd's private /tmp directory (/tmp/systemd-private-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-httpd.service-XXXXXX/tmp). This directory can't be found by other processes such as passenger-config or passenger-status.

This problem owes to Systemd's PrivateTmp, so it may also occurs on RHEL7 or Amazon Linux 2.

Workaround 1: Explicitly specify PassengerInstanceRegistryDir

This workaround remains Systemd's PrivateTmp enabled.
Explicitly specify Passenger's instance registry directory so that instance registry dir is not made in httpd's private /tmp directory.

First, I made PassengerInstanceRegistryDir to be created in /var/run, but since systemd-239 or later displays the following warning, I have modified it to be created in /run.
[/etc/tmpfiles.d/passenger.conf:1] Line references path below legacy directory /var/run/, updating /var/run/passenger-instreg → /run/passenger-instreg; please update the tmpfiles.d/ drop-in file accordingly.

Systemd logs warnings about the legacy tmpfile location /var/run - Red Hat Customer Portal

(on Apache)
/etc/httpd/conf/httpd.conf

PassengerInstanceRegistryDir /run/passenger-instreg

Because files and directories in /run is deleted on reboot, you must add config file in tmpfiles.d.
See man 5 tmpfiles.d for details.

/etc/tmpfiles.d/passenger.conf

D /run/passenger-instreg 0755 root root

You must add PASSENGER_INSTANCE_REGISTRY_DIR for the users who executes passenger-status and passenger-config.

~/.bash_profile

export PASSENGER_INSTANCE_REGISTRY_DIR=/run/passenger-instreg

If you use capistrano-passenger, you must set PASSENGER_INSTANCE_REGISTRY_DIR in the stage's deploy recipe because capistrano-passenger executes `passenger-config restart-app`.

set :default_env, {
  ...(omit)..,
  "PASSENGER_INSTANCE_REGISTRY_DIR" => "/run/passenger-instreg"
}

Finally restart system.

Workaround 2: Disable PrivateTmp on httpd.service

This workaround disables Systemd's PrivateTmp on httpd.service.

$ sudo systemctl edit httpd.service
[Service]
PrivateTmp=false

Then execute below.

$ sudo systemctl restart httpd.service

Manually copying files under /usr/lib/systemd/system/ is not recommended, so I fixed to use `systemctl edit`. Using `systemctl edit`, systemd configuration is automatically reloaded (in a way that is equivalent to daemon-reload).

Copy /usr/lib/systemd/system/httpd.service to /etc/systemd/system and edit it.

/etc/systemd/system/httpd.service

...(omit)
PrivateTmp=false
...(omit)

Then execute below.

$ sudo systemctl daemon-reload
$ sudo systemctl restart httpd.service

Source: CentOS 7 で Phusion Passenger の passenger-status を実行するとエラーとなる - Qiita
お前らもさっさとハマって泣くべきCentOS7の落とし穴4つ - Qiita
Handle systemd PrivateTmp #1475
Systemd入門(5) - PrivateTmpの実装を見る - めもめも