The "Signature Algorithm" describes what kind of signature was used by Let's Encrypt's intermediate certificate to sign your leaf certificate. By default, unless you've specifically opted-in to get signed by an ECDSA intermediate, your certificates will be signed with the RSA intermediate. That's the "sha256WithRSAEncryption" you see. That's the same whether your key, used by your certificate to secure a connection, is an RSA or ECDSA key.
You'll want to look at the "key size" and "public key algorithm" and the like to see which kind of public key your certificate uses itself.
well
I set in cPanel ssl to ecdsa type and i see (sectigo) X9.62 ECDSA Signature with SHA-256 as Signature Algorithm
same confirmed by ssl checkers
in a certbot case with default settings I do not see it anywhere, only in possible cipher list.
You can check any server protected by certbot certificate, I do not see any difference in ssl checker with RSA or ECDSA
update
with zerossl i see X9.62 ECDSA Signature with SHA-256 as Signature Algorithm
I agree with my fellow volunteers that what you've written in your opening post (the first post of the thread) that a ECDSA cert was signed by R3, an RSA intermediate.
Also note that the certs known to Certbot aren't necessarily also the certs that are installed in the webserver.
I think that you're just conflating concepts here, though I can see how they can be confusing.
You can choose to have an RSA or ECDSA key in your certificate. (And most systems work fine with either, though a couple oddballs don't support ECDSA.)
The CA can similarly choose to have an RSA or ECDSA key in its intermediate certificate that it uses to sign yours. (And most systems similarly work fine with either.) They can use an RSA key to sign an ECDSA-keyed certificate, or vice-versa even.
The "Signature Algorithm" that you see just tells you the latter. Which may be interesting to know, but doesn't really matter unless you're trying to diagnose an issue with some oddball system that doesn't support the signature algorithm.
Let's Encrypt uses RSA signatures for almost everything, unless you've specifically opted-in to get the ECDSA signature of your ECDSA-keyed certificates.
Other CAs do other things. Having ECDSA-keyed certificates signed by ECDSA intermediates is very common, and Let's Encrypt will (hopefully) be switching to do so more often (rather than being on an opt-in basis only) at some point "soon". I'm not surprised that the other CAs that you're testing are doing so.
Is there some actual problem you're trying to resolve, or are you just "nosy" (which is a good thing; I certainly am with this stuff) and curious why you see different things in different places?
Yes, I do.
All you do is mention SSL checker and ZeroSSL but you don't show us any real information nor domain.
Cipher lists have very little to do with certificate types [only indirectly].
Any type can sign any [other] type.
Think of them as literal keys and keychains/keyrings.
The keychain can be gold or silver and the keys can be silver or gold [or 14K or 18K]; It makes no difference, the keychain will hold all those keys.
You're linking here to the generic home page of the SSL Test service.
You said YOU have certificates issued with Certbot 2.6.0. Please provide actual example hostnames for which you're having doubts or troubles and please specify which troubles you have, if any.
Yeah, that's simply a certificate containing a ECDSA public key, signed by the RSA intermediate "R3".
If you want your ECDSA certificates signed by the ECDSA intermediate E1, you need to sign up for the opt-in allow-list mentioned here: ECDSA availability in production environment
In practice, it doesn't really matter if your chain is ECDSA only or a combination of ECDSA and RSA. Only with HUGE amount of connections, the size of the certificate (due to the size of the public key and signature) matters.