# Ensure that the Docker server certificate key file permissions are set to 400

- Source: https://support.icompaas.com/support/solutions/articles/62000234343-ensure-that-the-docker-server-certificate-key-file-permissions-are-set-to-400
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS Docker Benchmark v1.7.0](https://support.icompaas.com/support/solutions/62000112687) › [CIS Docker Benchmark](https://support.icompaas.com/support/solutions/folders/62000169241)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Profile Applicability:**

-   **Level 1**
    

**Description:**

The Docker server certificate key file, which is used for secure TLS communication between the Docker client and daemon, should have its permissions set to 400 (read-only for the root user). This ensures that the key file cannot be modified or read by unauthorized users, maintaining the integrity of secure communications.

**Rationale:**

The server certificate key is a sensitive file that must remain protected to ensure secure communication. If unauthorized users gain access to the key, they could potentially intercept or decrypt traffic between the Docker client and daemon. By setting the permissions to 400, the file is protected from modifications, while still allowing the Docker daemon to read it for secure communication.

**Impact:**

**Pros:**

-   Protects the Docker server certificate key file by preventing unauthorized access or modifications.
    
-   Helps maintain the confidentiality and integrity of the TLS key used for secure communication.
    

**Cons:**

-   If the certificate key file needs to be updated, the permissions must be temporarily changed, adding an extra step to the process.
    

**Default Value:**

By default, the Docker server certificate key file may have 644 permissions, which allow read and write access to the root user and read access to others. It should be changed to 400 to secure it.

**Pre-requisites:**

-   Administrative privileges on the Docker host system.
    
-   Access to the file system to inspect and modify permissions.
    

**Remediation:**

**Test Plan:**

**Using AWS Console:**

1.  Log in to the EC2 instance running Docker.
    
2.  Verify the permissions of the Docker server certificate key file:  
    
    ls -l /etc/docker/certs.d/<registry>/server-key.pem
    

**Using AWS CLI:**

1.  Connect to the EC2 instance where Docker is running.
    
2.  Run the following command to check the permissions of the Docker server certificate key file:  
    
    ls -l /etc/docker/certs.d/<registry>/server-key.pem
    

**Implementation Plan:**

**Using AWS Console:**

1.  Log in to the EC2 instance.
    
2.  Set the permissions of the Docker server certificate key file to 400:  
    
    sudo chmod 400 /etc/docker/certs.d/<registry>/server-key.pem
    
3.  Restart Docker to ensure the changes take effect:  
    
    sudo systemctl restart docker
    

Using AWS CLI:

1.  Use SSM to modify the permissions of the Docker server certificate key file and restart Docker:  
    
    aws ssm send-command --document-name "AWS-RunShellScript" --targets "Key=instanceIds,Values=instance\_id" --parameters 'commands=\["sudo chmod 400 /etc/docker/certs.d/<registry>/server-key.pem && sudo systemctl restart docker"\]'
    

**Backout Plan:**

**Using AWS Console:**

1.  Log in to the EC2 instance.
    
2.  Revert the permissions of the Docker server certificate key file if necessary:  
    
    sudo chmod 644 /etc/docker/certs.d/<registry>/server-key.pem
    
3.  Restart Docker:
    

**Using AWS CLI:**

1.  Use SSM to revert the permissions and restart Docker:  
    
    aws ssm send-command --document-name "AWS-RunShellScript" --targets "Key=instanceIds,Values=instance\_id" --parameters 'commands=\["sudo chmod 644 /etc/docker/certs.d/<registry>/server-key.pem && sudo systemctl restart docker"\]'
    

**References:**

-   [Docker TLS Security](https://docs.docker.com/engine/security/https/)
    
-   [Docker Registry Insecure Setup](https://docs.docker.com/registry/insecure/)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.