Certificate Common name and Subject Alternate Name

WILDCARD(*) SSL CERTIFICATE IN COMMON NAME (CN)

By Nadeemullah Mohamed • Thursday March 31, 2016 • Custom Solutions

Recently I faced with an issue with a wildcard(*) in Common Name(CN) in SSL certificate. Invoking a SOAP end point over SSL through a standalone java web services client was complaining with an error “the https URL hostname does not match the Common Name (CN) on the server certificate in the client’s truststore.”

WildCard SSL certificates

Wildcard SSL certificates secure a website and an unlimited number of its first level subdomains. A SSL certificate with CN=*.mycompany.com is called a WildCard certificate. This wildcard SSL certificate would protect a.mycompany.com, b.mycompany.com, c.mycompany.com and so on and so forth. But this certificate will not work if the certificate is used for second, third and other sublevel domains, unless the sublevel domains are added in Subject Alternate Name(SAN) in the certificate.

Example

A SSL certificate which has CN=*.mycompany.com will not work for “blog.subdomain.mycompany.com”, unless “blog.subdomain.mycompany.com” is added in Subject Alternate Name (SAN).

Below describes the environment where I encountered the issue and also the solution for the issue:

Environment

A Dynamic Invocation Interface (DII) web service java client invoking .NET SOAP web service. The DII web service java client is a standalone java application running on JRE 7.

The Fully Qualified Domain Name(FQDN) in SOAP end point https://hostname.subdomain.mycompany.com

Certificate Setup

CN=*.mycompany.com

SubjectAlternativeName [

DNSName: *.mycompany.com

DNSName: mycompany.com

DNSName: subdomain.mycompany.com

]

Issue The way the SSL certificate was setup.

Solution

A new certificate was setup by adding “hostname.subdomain.mycompany.com(FQDN)” in Subject Alternate Name(SAN). Below is how the new certificate was setup which resolved the issue.

New Certificate Setup

CN=*.mycompany.com

SubjectAlternativeName [

DNSName: *.mycompany.com

DNSName: mycompany.com

DNSName: hostname.subdomain.mycompany.com

]

References:

https://www.idmworks.com/wildcard-ssl-certificate-in-common-name-cn/

Python Module Level logger

The logging library takes a modular approach and offers several categories of components: loggers, handlers, filters, and formatters.

Loggers expose the interface that application code directly uses.

Handlers send the log records (created by loggers) to the appropriate destination.

Filters provide a finer grained facility for determining which log records to output.

Formatters specify the layout of log records in the final output.

Logging is performed by calling methods on instances of the Logger class (hereafter called loggers). Each instance has a name, and they are conceptually arranged in a namespace hierarchy using dots (periods) as separators. For example, a logger named ‘scan’ is the parent of loggers ‘scan.text’, ‘scan.html’ and ‘scan.pdf’. Logger names can be anything you want, and indicate the area of an application in which a logged message originates.

A good convention to use when naming loggers is to use a module-level logger, in each module which uses logging, named as follows:

logger = logging.getLogger(__name__)

References:

https://docs.python.org/3/howto/logging.html#logging-basic-tutorial

Docker how to configure container level Docker

sudo docker inspect -f '{{.HostConfig.LogConfig.Type}}'  78634dcef146

This gives which log driver is used. If json is used, it gives json-file as the output 

Very useful set of Docker commands

Refereces 

https://blog.softwaremill.com/how-to-keep-your-docker-installation-clean-98a74eb7e7b3

https://www.digitalocean.com/community/tutorials/how-to-remove-docker-images-containers-and-volumes

https://stackoverflow.com/questions/53221412/why-the-none-image-appears-in-docker-and-how-can-we-avoid-it

References:

What are two commands which can let know the running containers etc

 docker version 

docker info 

These two give good information about the Docker that is running. 

Cleaning up Docker containers

The command sudo du $dir -hk --max-depth=2 | sort -k2 was listing all the directories in alphabetical order 

https://github.com/docker/compose/issues/3262

https://stackoverflow.com/questions/51238891/how-to-fix-the-running-out-of-disk-space-error-in-docker

https://puvox.software/blog/solution-clean-full-disk-space-by-dev-vda1/

Docker Compose how to view log files

To view the log files , just can do one of the below 

docker-compose logs

docker-compose logs <<name of the service>>

Now to limit the output, can do something like this

docker-compose logs --no-color --tail=1000 <service-name> > logs.txt

References:

https://support.onegini.com/hc/en-us/articles/115000379192-How-to-show-docker-compose-container-logs

What Is a Docker Container?

 

What is Docker container, image 

A container is a unit of software that packages an application, making it easy to deploy and manage no matter the host. Say goodbye to the infamous “it works on my machine” statement!

How? Containers are isolated and stateless, which enables them to behave the same regardless of the differences in infrastructure. A Docker container is a runtime instance of an image that’s like a template for creating the environment you want.

What Is a Docker Image?

A Docker image is an executable package that includes everything that the application needs to run. This includes code, libraries, configuration files, and environment variables.

Why Do You Need Containers?

Containers allow breaking down applications into microservices – multiple small parts of the app that can interact with each other via functional APIs. Each microservice is responsible for a single feature so development teams can work on different parts of the application at the same time. That makes building an application easier and faster.

References:

https://sematext.com/guides/docker-logs/

Docker logger, what all it captures?

 By default, Docker captures the standard output (and standard error) of all your containers, and writes them in files using the JSON format. The JSON format annotates each line with its origin (stdout or stderr) and its timestamp. Each log file contains information about only one container.

{"log":"Log line is here\n","stream":"stdout","time":"2019-01-01T11:11:11.111111111Z"}

References:

https://docs.docker.com/config/containers/logging/json-file/