: mode=TCP side=FE|BE mux=PASS flags=
none : mode=TCP side=FE|BE mux=PASS flags=NO_UPG
Available services : prometheus-exporter
Available filters :
[CACHE] cache
[COMP] compression
[FCGI] fcgi-app
[SPOE] spoe
[TRACE] trace
```
I test TLSv1.0 & TLSv1.2 support from a Ubuntu Xenial VM using curl:
```auto
curl --tlsv1.0 -vvv https://old.example.org
curl --tlsv1.2 -vvv https://old.example.org
```
---
### Author:  [@cuu508](https://discourse.haproxy.org/u/cuu508)
#### Post date: [March 7, 2023, 7:12am UTC](https://discourse.haproxy.org/t/ssl-min-ver-in-crt-list-used-to-work-with-haproxy-2-2-does-not-seem-to-work-with-haproxy-2-6/8455/2 "2023-03-07T07:12:18Z")
I experimented with multiple `crt` directives as an alternative to `crt-list`:
```auto
ssl-default-bind-options ssl-min-ver TLSv1.0 no-tls-tickets
frontend www
bind *:443 ssl crt old.example.com.pem ssl-min-ver TLSv1.0 crt modern.example.com.pem ssl-min-ver TLSv1.2
bind :::443 ssl crt old.example.com.pem ssl-min-ver TLSv1.0 crt modern.example.com.pem ssl-min-ver TLSv1.2
```
Haproxy seemed to use the same ssl-min-ver for both both domains. In the above example, both domains worked with TLSv1.2+ only.
If I switched the crt directives around, _both_ domains worked with TLSv1.0+:
```auto
ssl-default-bind-options ssl-min-ver TLSv1.0 no-tls-tickets
frontend www
bind *:443 ssl crt modern.example.com.pem ssl-min-ver TLSv1.2 crt old.example.com.pem ssl-min-ver TLSv1.0
bind :::443 ssl crt modern.example.com.pem ssl-min-ver TLSv1.2 crt old.example.com.pem ssl-min-ver TLSv1.0
```
---
### Author:  [@cuu508](https://discourse.haproxy.org/u/cuu508)
#### Post date: [March 7, 2023, 7:55am UTC](https://discourse.haproxy.org/t/ssl-min-ver-in-crt-list-used-to-work-with-haproxy-2-2-does-not-seem-to-work-with-haproxy-2-6/8455/3 "2023-03-07T07:55:06Z")
After some more experimenting, it seems like `ssl-min-ver` in crt-list is simply ignored.
If `ssl-min-ver` is defined on the `bind` line, haproxy uses that.
Otherwise, if `ssl-min-ver` is defined in `ssl-default-bind-options`, haproxy uses that.
Otherwise, it uses the default TLSv1.2 value.
Haproxy does parse and read `ssl-min-ver` from the crt-list file. If I specify a bad value in the crt-list file, haproxy does complain about it:
```auto
[ALERT] (78775) : config : parsing [/etc/haproxy/haproxy.cfg:38] : 'bind *:443' in section 'frontend' : 'crt-list' : 'TLSv1.123' : unknown ssl/tls version
```
But for some reason it does not use it…
---
### Author:  [@lukastribus](https://discourse.haproxy.org/u/lukastribus)
#### Post date: [March 7, 2023, 8:15am UTC](https://discourse.haproxy.org/t/ssl-min-ver-in-crt-list-used-to-work-with-haproxy-2-2-does-not-seem-to-work-with-haproxy-2-6/8455/4 "2023-03-07T08:15:27Z")
Are the names on dedicated non overlapping certificates? Do other option for the specific domain name work that are configured in crt-list?
The question is, does that particular line in crt-list actually match, or does it actually not match at all.
---
### Author:  [@cuu508](https://discourse.haproxy.org/u/cuu508)
#### Post date: [March 7, 2023, 8:38am UTC](https://discourse.haproxy.org/t/ssl-min-ver-in-crt-list-used-to-work-with-haproxy-2-2-does-not-seem-to-work-with-haproxy-2-6/8455/5 "2023-03-07T08:38:17Z")
The CN values for the certificates do not overlap.
I did an experiment with different ALPN values:
```auto
old.example.com.pem [alpn h2,http/1.1,http/1.0 ssl-min-ver TLSv1.0]
modern.example.com.pem [alpn h2 ssl-min-ver TLSv1.2]
```
I get different output in curl when requesting them:
```auto
curl --tlsv1.2 -vvv https://old.example.com
* ALPN, offering http/1.1
[...]
* ALPN, server accepted to use http/1.1
```
and
```auto
curl --tlsv1.2 -vvv https://modern.example.com
* ALPN, offering http/1.1
[...]
* ALPN, server did not agree to a protocol
```
So it seems the per-domain `alpn` directive did have an effect.
One more note: I’m using both ECDSA and RSA certificates. In the certificates directory I have:
- old.example.com.pem.rsa
- old.example.com.pem.ecdsa
- modern.example.com.pem.rsa
- modern.example.com.pem.ecdsa
---
### Author:  [@lukastribus](https://discourse.haproxy.org/u/lukastribus)
#### Post date: [March 7, 2023, 8:40am UTC](https://discourse.haproxy.org/t/ssl-min-ver-in-crt-list-used-to-work-with-haproxy-2-2-does-not-seem-to-work-with-haproxy-2-6/8455/6 "2023-03-07T08:40:45Z")
Ok, I think at this point there is enough information to file a bug report on Github, please make sure you mention all the informations from the last post too:
> **[Build software better, together](https://github.com/haproxy/haproxy/issues/new/choose)**
>
> GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 330 million projects.
---
### Author:  [@cuu508](https://discourse.haproxy.org/u/cuu508)
#### Post date: [March 7, 2023, 9:09am UTC](https://discourse.haproxy.org/t/ssl-min-ver-in-crt-list-used-to-work-with-haproxy-2-2-does-not-seem-to-work-with-haproxy-2-6/8455/7 "2023-03-07T09:09:10Z")
OK, filed a bug report: [Ssl-min-ver in crt-list used to work with haproxy 2.2, does not seem to work with haproxy 2.6 · Issue #2069 · haproxy/haproxy · GitHub](https://github.com/haproxy/haproxy/issues/2069)