Verifying File Permissions and Ownership
The first step in troubleshooting any SSL configuration failure is to ensure that the Nginx process has the necessary rights to read the private key and certificate files. Nginx typically runs under thewww-data or nginx user depending on your Linux distribution. If the PEM files are owned by root or another user with restrictive permissions, Nginx will be unable to load them, resulting in a startup failure or a 502 Bad Gateway error.
To diagnose this, check the current permissions of your certificate directory using the following command:
ls -l /etc/ssl/certs/ionos/
ls -l /etc/ssl/private/ionos/
You should see that the files are readable by the group or others, or specifically owned by the Nginx user. If the permissions are set to 600 and owned by root, you must adjust them. While it is secure to keep the private key at 600, you must change the owner to the Nginx user. Run the following commands to correct ownership:
sudo chown www-data:www-data /etc/ssl/private/ionos/your_domain.key
sudo chown www-data:www-data /etc/ssl/certs/ionos/your_domain.crt
If you are using a custom Nginx user, replace www-data with that username. After changing ownership, test the configuration again with sudo nginx -t. If the permission issue was the cause, this test will pass. This step is critical because many users mistakenly try to fix SSL errors by disabling verification instead of addressing the underlying access control problem. For more details on why disabling checks is dangerous, see How to disable SSL checking on Nginx?.
Ensuring the Full Certificate Chain
Ionos provides certificates that often require an intermediate CA (Certificate Authority) bundle to establish a trusted chain of trust. If you only provide the leaf certificate (the domain certificate) without the intermediate certificates, browsers and clients may reject the connection, or Nginx may fail to validate the context properly. The Nginx directivessl_certificate expects the full chain, meaning your domain certificate followed by the intermediate certificates, all concatenated into a single file.
Download the intermediate certificate bundle from the Ionos customer panel or their support documentation. It usually comes as a separate file, such as intermediate.crt or ca-bundle.crt. You need to concatenate your domain certificate and the intermediate bundle into one file. Use the following command structure, replacing filenames with your actual Ionos-provided names:
cat /etc/ssl/certs/ionos/domain.crt /etc/ssl/certs/ionos/intermediate.crt > /etc/ssl/certs/ionos/full_chain.pem
Update your Nginx server block to point to this new combined file:
server {
listen 443 ssl;
server_name your_domain.com;
ssl_certificate /etc/ssl/certs/ionos/full_chain.pem;
ssl_certificate_key /etc/ssl/private/ionos/domain.key;
# ... other directives
}
This ensures that when Nginx presents the certificate to the client, it includes the necessary links to the root CA. Without this, the handshake may complete, but security warnings will appear in browsers. If you are dealing with more complex proxy setups where context is ignored, refer to Troubleshooting Nginx-proxy Ignoring Server Context.
Validating Key and Certificate Match
A frequent source of confusion is a mismatch between the private key and the public certificate. This can happen if you generate a new key by mistake or if the PEM file from Ionos contains multiple keys. Nginx will explicitly report this with an error like "private key does not match the certificate public key." To verify that they correspond to each other, compare the modulus values of both files. Run these two commands and compare the output strings:openssl x509 -noout -modulus -in /etc/ssl/certs/ionos/domain.crt | openssl md5
openssl rsa -noout -modulus -in /etc/ssl/private/ionos/domain.key | openssl md5
Both commands should return the exact same hash string. If they differ, you have the wrong key for that certificate. In this case, you must re-download the correct private key from the Ionos dashboard. Ensure that the private key file is in PKCS#1 or PKCS#8 format, which are standard for OpenSSL and Nginx. If the key appears corrupted or in an unsupported format, convert it using OpenSSL tools before placing it back in the Nginx directory.
Checking for Syntax Errors in PEM Files
Sometimes the PEM file downloaded from Ionos may contain extra whitespace, Windows-style line endings (CRLF), or hidden characters that confuse the parser. Nginx is strict about PEM formatting. If the previous steps do not resolve the issue, inspect the raw content of the key file. Use a text editor orcat -A to view hidden characters:
cat -A /etc/ssl/private/ionos/domain.key
Look for carriage returns indicated by ^M at the end of lines. If present, remove them using dos2unix:
sudo apt-get install dos2unix
sudo dos2unix /etc/ssl/private/ionos/domain.key
After cleaning the file, run sudo nginx -t again. A successful configuration test indicates that the syntax is now valid.
Frequently Asked Questions
Why does Nginx say 'unable to get local issuer certificate'?
This error means the intermediate certificate is missing from your ssl_certificate file. You must append the Ionos intermediate bundle to your domain certificate so the full chain is presented. Without it, clients cannot verify the trust path to the root CA.
Can I use a self-signed certificate instead of the Ionos PEM?
You can technically use a self-signed certificate for testing, but it will trigger browser security warnings for real users. Production environments require valid certificates from a trusted authority like Ionos to ensure secure connections and SEO benefits.
What if my Ionos key file is encrypted with a passphrase?
Nginx cannot start if the private key requires a passphrase interactively. You must either remove the passphrase from the key using OpenSSL or configure a script to supply it during startup, though removing the passphrase is the standard practice for web servers.
Does changing permissions break SSL encryption?
No, changing file ownership to the Nginx user does not weaken encryption. It simply allows the service to read the necessary files. Encryption strength depends on the algorithm used (e.g., RSA 2048-bit), not on who owns the file on the disk.
How do I verify the certificate is actually loaded after restart?
Use the command openssl s_client -connect your_domain.com:443 -servername your_domain.com to connect to your server. Check the output for the certificate chain details. If the chain ends with your domain cert and shows the intermediate, it is correctly loaded.