Custom Certificate Issue #82

dpaessler · 2026-01-25T11:17:13Z

dpaessler
Jan 25, 2026

I got almost everything working now (see here)

I got my static Website working with a custom Docker volume, I can access all my Web Interfaces through HTTPS with a valid Certificate under several subdomains by importing my Let's Encrypt cert.pem certificates.
So far, so good :)
However, I have one issue remaining:

Some Services (other than Websites) fail. For example, I have a Nextcloud (https://nextcloud.com) hosted on one of my computers, which is accessible through "https://cloud.server.com".
I successfully can access the Web Interface, however, there are some other Services on that Nextcloud Instance which fail.

Investigating these Issues, I found, that it seems to fail to verify the Root CA or the Intermediate CA Certificate.

On my former Apache Reverse Proxy, I had these Lines in my conffiguration and everything worked:

SSLCertificateFile /etc/letsencrypt/live/cloud.server.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/cloud.server.com/privkey.pem

So I removed the cert.pem Certificates from nginx ignition and replaced them with the corresponding fullchain.pem, which, as you stated here also contains the full chain and the Server Certificate itself.

They got imported successfully and I still can access the Website through "https://cloud.server.com" with a valid Certificate, but the other Services still fail verifying the Root CA or the Intermediate CA Certificate.

Investigating using cURL, with my former Apache Reverse Proxy everything works as expected:

`curl -v https://cloud.server.com

Host cloud.server.com:443 was resolved.
IPv6: (none)
IPv4: xxx.xxx.xxx.xxx
Trying xxx.xxx.xxx.xxx:443...
ALPN: curl offers h2,http/1.1
TLSv1.3 (OUT), TLS handshake, Client hello (1):
SSL Trust Anchors:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
TLSv1.3 (IN), TLS handshake, Certificate (11):
TLSv1.3 (IN), TLS handshake, CERT verify (15):
TLSv1.3 (IN), TLS handshake, Finished (20):
TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.3 (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS
ALPN: server accepted http/1.1
Server certificate:
subject: CN=cloud.server.com
start date: Dec 4 14:56:17 2025 GMT
expire date: Mar 4 14:56:16 2026 GMT
issuer: C=US; O=Let's Encrypt; CN=R12
Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
subjectAltName: "cloud.server.com" matches cert's "cloud.server.com"
SSL certificate verified via OpenSSL.
Established connection to cloud.server.com (xxx.xxx.xxx.xxx port 443) from xxx.xxx.xxx.xxx port 54302
using HTTP/1.x

GET / HTTP/1.1
Host: cloud.server.com
User-Agent: curl/8.18.0
Accept: /

Request completely sent off
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 302 Found
< Date: Sun, 25 Jan 2026 10:34:52 GMT
< Server: Apache
< Strict-Transport-Security: max-age=15552000; includeSubDomains
< X-Powered-By: PHP/8.4.17
< Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-xr8Tw2JNFkBu7lnbznGExC6YpVrIlPgTxGivzNk2xwk='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< Referrer-Policy: no-referrer
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: noindex, nofollow
< Strict-Transport-Security: max-age=15552000
< Location: https://cloud.server.com/nextcloud/index.php/login
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
< Set-Cookie: oc_sessionPassphrase=C044zNZ7%2FudRYev8Lf9d9cc4EnEi794xURR7jhyu2kKJUHLANOA394s57Gxfceg5iIJ5aBBllIy%2BniNOeHPh6qLiSNt4smzb%2FlP%2FfNbEntk8w4RqwIS3ZUoh2YDW72er; path=/nextcloud; secure; HttpOnly; SameSite=Lax
< Set-Cookie: nc_sameSiteCookielax=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< Set-Cookie: nc_sameSiteCookiestrict=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< Set-Cookie: ocz8bfoh2z5k=cb895479a84aea03d7a2aea4c954ce3f; path=/nextcloud; secure; HttpOnly; SameSite=Lax
< Via: 1.1 cloud.server.com
<
Connection #0 to host cloud.server.com:443 left intact`

But with nginx ignition I get the same error as with the cert.pem:

`curl -v https://cloud.server.com

Host cloud.server.com:443 was resolved.
IPv6: (none)
IPv4: xxx.xxx.xxx.xxx
Trying xxx.xxx.xxx.xxx:443...
ALPN: curl offers h2,http/1.1
TLSv1.3 (OUT), TLS handshake, Client hello (1):
SSL Trust Anchors:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
TLSv1.3 (IN), TLS handshake, Certificate (11):
TLSv1.3 (IN), TLS handshake, CERT verify (15):
TLSv1.3 (IN), TLS handshake, Finished (20):
TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.3 (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / RSASSA-PSS
ALPN: server accepted h2
Server certificate:
subject: CN=cloud.server.com
start date: Dec 4 14:56:17 2025 GMT
expire date: Mar 4 14:56:16 2026 GMT
issuer: C=US; O=Let's Encrypt; CN=R12
Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
subjectAltName: "cloud.server.com" matches cert's "cloud.server.com"
SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
closing connection #0
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.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 webpage mentioned above.`

So the Server Certificate still is valid, but the Certificate chain fails to verify.

Answered by lucasdillmann

Jan 26, 2026

@dpaessler, I was able to reproduce the problem and understand what is happening.

In summary: An empty line at the end of the chain.pem file is what was causing the problem, preventing Nginx Ignition from correctly importing the certificate, which is a bug.

By fixing this and importing the certificate using the three separate files (cert.pem as the public key, privkey.pem as the private key, and chain.pem as the certification chain), Nginx was configured correctly. The curl command now works on tests I've made, showing the same output as Apache.

curl output before the fix

# curl -v https://importtest.lan.dillmann.dev:8443
* Host importtest.lan.dillmann.dev:8443 was resolved.
* IPv6: (none…

View full answer

lucasdillmann · 2026-01-26T03:18:37Z

lucasdillmann
Jan 26, 2026
Maintainer

Hi @dpaessler. I'm sorry to hear that you are still having difficulty importing an external certificate.

Please give me some time to reproduce the problem and understand what might be happening (thanks for all the details you shared). I will get back to you here with more details soon.

3 replies

dpaessler Jan 26, 2026
Author

Hi Lucas,

Thanks for your reply and for taking a look at this.
I really love nginx ignition and appreciate your work on it.

lucasdillmann Jan 26, 2026
Maintainer

@dpaessler, I was able to reproduce the problem and understand what is happening.

In summary: An empty line at the end of the chain.pem file is what was causing the problem, preventing Nginx Ignition from correctly importing the certificate, which is a bug.

By fixing this and importing the certificate using the three separate files (cert.pem as the public key, privkey.pem as the private key, and chain.pem as the certification chain), Nginx was configured correctly. The curl command now works on tests I've made, showing the same output as Apache.

curl output before the fix

# curl -v https://importtest.lan.dillmann.dev:8443
* Host importtest.lan.dillmann.dev:8443 was resolved.
* IPv6: (none)
* IPv4: 192.168.0.221
*   Trying 192.168.0.221:8443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
*   subject: CN=importtest.lan.dillmann.dev
*   start date: Jan 26 21:14:54 2026 GMT
*   expire date: Apr 26 21:14:53 2026 GMT
*   issuer: C=US; O=Let's Encrypt; CN=E7
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   subjectAltName: "importtest.lan.dillmann.dev" matches cert's "importtest.lan.dillmann.dev"
* SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
* closing connection #0
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.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 webpage mentioned above.

curl output after the fix

# curl -v https://importtest.lan.dillmann.dev:8443
* Host importtest.lan.dillmann.dev:8443 was resolved.
* IPv6: (none)
* IPv4: 192.168.0.221
*   Trying 192.168.0.221:8443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
*   subject: CN=importtest.lan.dillmann.dev
*   start date: Jan 26 21:14:54 2026 GMT
*   expire date: Apr 26 21:14:53 2026 GMT
*   issuer: C=US; O=Let's Encrypt; CN=E7
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "importtest.lan.dillmann.dev" matches cert's "importtest.lan.dillmann.dev"
* SSL certificate verified via OpenSSL.
* Established connection to importtest.lan.dillmann.dev (192.168.0.221 port 8443) from 192.168.0.4 port 36838 
* using HTTP/1.x
> GET / HTTP/1.1
> Host: importtest.lan.dillmann.dev:8443
> User-Agent: curl/8.17.0
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 26 Jan 2026 22:48:31 GMT
< Content-Type: application/octet-stream
< Content-Length: 0
< Last-Modified: Mon, 26 Jan 2026 22:37:21 GMT
< Connection: keep-alive
< ETag: "6977eca1-0"
< Accept-Ranges: bytes
< 
* Connection #0 to host importtest.lan.dillmann.dev:8443 left intact

I've just released version 2.29.1 with this fix. Could you please try it out and let me know if it works as expected? If it doesn't, I will keep looking into this.

One thing to note: you will need to re-import the certificate by selecting the three separate files. Unfortunately, this specific fix does not resolve imports using a fullchain.pem file.

Last but not least, thanks for the bug report and for the feedback.

Answer selected by dpaessler

dpaessler Jan 27, 2026
Author

Hi,

Wow, that was a fast fix and it is indeed working as expected now. Thank you very much for your effort and the quick help on this.

Cheers

Navigation Menu

Custom Certificate Issue #82

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 1 comment 3 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Select a reply

Uh oh!

Custom Certificate Issue #82

Uh oh!

Uh oh!

dpaessler Jan 25, 2026

Replies: 1 comment · 3 replies

Uh oh!

Uh oh!

lucasdillmann Jan 26, 2026 Maintainer

Uh oh!

dpaessler Jan 26, 2026 Author

Uh oh!

lucasdillmann Jan 26, 2026 Maintainer

Uh oh!

Uh oh!

dpaessler Jan 27, 2026 Author

dpaessler
Jan 25, 2026

Replies: 1 comment 3 replies

lucasdillmann
Jan 26, 2026
Maintainer

dpaessler Jan 26, 2026
Author

lucasdillmann Jan 26, 2026
Maintainer

dpaessler Jan 27, 2026
Author