mohammed90
commented
1 month ago I'm not able to replicate your experience. Here's my config and the log of OpenSSL:
{
local_certs
storage file_system ./data
}
localhost {
tls {
key_type rsa2048
}
respond "Ok"
}
$ openssl s_client -connect 127.0.0.1:443 -servername localhost
Connecting to 127.0.0.1
CONNECTED(00000384)
depth=1 CN=Caddy Local Authority - ECC Intermediate
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0
verify return:1
---
Certificate chain
0 s:
i:CN=Caddy Local Authority - ECC Intermediate
a:PKEY: rsaEncryption, 2048 (bit); sigalg: ecdsa-with-SHA256
v:NotBefore: Sep 16 07:41:26 2024 GMT; NotAfter: Sep 16 19:41:26 2024 GMT
1 s:CN=Caddy Local Authority - ECC Intermediate
i:CN=Caddy Local Authority - 2024 ECC Root
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
v:NotBefore: Sep 16 07:40:49 2024 GMT; NotAfter: Sep 23 07:40:49 2024 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICijCCAi+gAwIBAgIRALSti4Eqh/Bcj1jPS3/vgIYwCgYIKoZIzj0EAwIwMzEx
MC8GA1UEAxMoQ2FkZHkgTG9jYWwgQXV0aG9yaXR5IC0gRUNDIEludGVybWVkaWF0
ZTAeFw0yNDA5MTYwNzQxMjZaFw0yNDA5MTYxOTQxMjZaMAAwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC4fpbjQ9YIfNhnuf78r2z6HRP7iISc/iYYniWg
3RqieaLYw+42Ze4GtphehXtM10+W4gOrTDNXbMujJTyZipB6PBsKvk8ddpfj3gp2
KClm4bDhfP2RtfAXW+VcLSpwtbvj+x8QoO4LkdNle/C8dNvCKh6WXdiXK1XH7Fn8
+k/RX2xCPfJkOA/ZEwRES0p06cHqNlB9Mgi87rsqeEKEfmA7h4pQDDbjZhR/HjZE
O1c5+L75MfwSVq3qAcZQTshQEraEVYXNfzTR6u718qN80j9shOfxxTuXGgN1DS5i
xvuIJ3GLaZVPmxpmv1r9LVyrIfsb1bq73IdJLvbG2qXRQWR7AgMBAAGjgYswgYgw
DgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAd
BgNVHQ4EFgQUmXyrTElWUXosPFBbZ5s4yUL8e1swHwYDVR0jBBgwFoAUCD80F6zL
sNPbF75yS+ukbNo1+6wwFwYDVR0RAQH/BA0wC4IJbG9jYWxob3N0MAoGCCqGSM49
BAMCA0kAMEYCIQDRvImv6w1SAgQe6Diw2Q04JjCd1549nS6RI0h1jvyzBQIhAJ8r
a1EuaJ1fScnzoLr18J7GhBfyKFw8dOZMtsC52ZUp
-----END CERTIFICATE-----
subject=
issuer=CN=Caddy Local Authority - ECC Intermediate
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1659 bytes and written 388 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 20 (unable to get local issuer certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_128_GCM_SHA256
Session-ID: 6940084ED105811887E02A47F45AC33726F890C4E4D631F320CCF69442C84802
Session-ID-ctx:
Resumption PSK: EBC61A79B9B0F217EC2AA6AC956B093437E685DF0579E47D5D250BCD43017F99
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 604800 (seconds)
TLS session ticket:
0000 - 2d 13 76 ef 1e fc fa d1-ab 8d 7c c3 dc a4 ed 0e -.v.......|.....
0010 - 03 2d 18 33 53 c9 0b 3f-4b e3 34 42 40 4f 09 9b .-.3S..?K.4B@O..
0020 - f8 db c1 1c 91 26 8b 11-a9 24 2b db 1e 38 ff 5a .....&...$+..8.Z
0030 - 42 9e 11 01 97 eb 0e 6a-34 9a eb 7c 58 16 19 4e B......j4..|X..N
0040 - af de 01 3a 8b a9 71 57-14 17 67 41 f1 a2 f6 73 ...:..qW..gA...s
0050 - 79 8c 73 bc 76 17 57 f5-a2 a7 9c 9a fc 24 70 54 y.s.v.W......$pT
0060 - 06 4a 81 8a 4a c7 6d ee-0f .J..J.m..
Start Time: 1726472680
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: no
Max Early Data: 0
---Can you help out more with the replication? Let's try with the template, maybe it'll help zero down on the culprit. Ideally, we need to be able to reproduce the bug in the most minimal way possible. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either.
I've attached a template below that will help make this easier and faster! This will require some effort on your part -- please understand that we will be dedicating time to fix the bug you are reporting if you can just help us understand it and reproduce it easily.
This template will ask for some information you've already provided; that's OK, just fill it out the best you can. :+1: I've also included some helpful tips below the template. Feel free to let me know if you have any questions!
Thank you again for your report, we look forward to resolving it!
Template
## 1. Environment
### 1a. Operating system and version
```
paste here
```
### 1b. Caddy version (run `caddy version` or paste commit SHA)
```
paste here
```
### 1c. Go version (if building Caddy from source; run `go version`)
```
paste here
```
## 2. Description
### 2a. What happens (briefly explain what is wrong)
### 2b. Why it's a bug (if it's not obvious)
### 2c. Log output
```
paste terminal output or logs here
```
### 2d. Workaround(s)
### 2e. Relevant links
## 3. Tutorial (minimal steps to reproduce the bug)
Helpful tips
-
Environment: Please fill out your OS and Caddy versions, even if you don't think they are relevant. (They are always relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.
-
Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it's actually a bug.
- 2c) Log output: Paste terminal output and/or complete logs in a code block. DO NOT REDACT INFORMATION except for credentials.
- 2d) Workaround: What are you doing to work around the problem in the meantime? This can help others who encounter the same problem, until we implement a fix.
- 2e) Relevant links: Please link to any related issues, pull requests, docs, and/or discussion. This can add crucial context to your report.
-
Tutorial: What are the minimum required specific steps someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:
- Start with an empty config. Add only the lines/parameters that are absolutely required to reproduce the bug.
- Do not run Caddy inside containers.
- Run Caddy manually in your terminal; do not use systemd or other init systems.
- If making HTTP requests, avoid web browsers. Use a simpler HTTP client instead, like
curl. - Do not redact any information from your config (except credentials). Domain names are public knowledge and often necessary for quick resolution of an issue!
- Note that ignoring this advice may result in delays, or even in your issue being closed. 😞 Only actionable issues are kept open, and if there is not enough information or clarity to reproduce the bug, then the report is not actionable.
Example of a tutorial:
Create a config file: ``` { ... } ``` Open terminal and run Caddy: ``` $ caddy ... ``` Make an HTTP request: ``` $ curl ... ``` Notice that the result is ___ but it should be ___.
nusnewob
mholt
I have a caddy instance using Route53 ACME challenge to generate RSA2048 TLS cert for a legacy app, caddy seems to ignore
tls { key_type rsa2048 }block.The caddy docker instance was built with Route53 module for Caddy.
Caddy version
Dockerfile
Caddy config
AWS creds were configured correctly in
/root/.aws/credentialsand cert forweb.example.devwas obtained correctly, however cert forlegacy.example.devwith blocktls { key_type rsa2048 }was ignored, the cert generated uses the same key type asweb.example.devusinged25519Caddy generates cert for domain with
tls { key_type rsa2048 }using key typersa2048console output
Log