Signature Algorithm with SHA256ECDSA

Feature Requests
1

Hi,

I generated a certificate with RSA public and private key. The certificate has Private key and PUblic key as RSA and SIgnature algorithm is SHA256withRSA.

Now i tried to change the certificate to SHA256withECDSA. So i have passed ECDSA private and public key to CSR. But the generated certificate still has Signature and Signature Algorithm as SHA256withRSA. But i need that to be signed with SHA256withECDSA. I have used Java client.

Here is my certificate generated with EC keys.

Certificate Version : 3
Serial Number : 21781255164169531867208678306871906768202318
Signature : SHA256withRSA
Issuer : CN=Fake LE Intermediate X1
Subject : CN=www.provteam.in
Certificate Validity :valid
Certificate [
[
Version: V3
Subject: CN=www.provteam.in
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

Key: Sun EC public key, 256 bits
public x coord: 15546637836353288101170932950429072647644820192651766716428014795363973491131
public y coord: 6146382100650817695530112138903471819592851370572017012053233788799056492102
parameters: org.bouncycastle.jce.spec.ECNamedCurveSpec@3bc81588
Validity: [From: Wed Feb 15 20:18:00 IST 2017,
To: Tue May 16 20:18:00 IST 2017]
Issuer: CN=Fake LE Intermediate X1
SerialNumber: [ fa095b22 b389d714 e4891488 bd8b824f 2a4e]

I can find why my certificate is doesnot have SHA256withECDSA signature.

Thanks in advance !!

2

The signature is generated by Let’s Encrypt (with the private key corresponding to the intermediate certificate you’ll find in the “Issuer” field) and currently Let’s Encrypt only has RSA certificates!

ECDSA certificates are planned though, see the Upcoming Features page.

Note: unless your Java is complaining, technically ECDSA certificates signed with a RSA signature is totally perfect and should work.
What’s the exact reason you need your cert signed with RSA256withECDSA?

1 Like
3

Thanks Osiris. I haven’t noticed that :blush: .
Ahh…That’s our client requirement.

4

Just for my curiosity: what client is that?

5

Is it still a possibility to have that feature in March @jsha?

6

I’m afraid ECDSA intermediates have been delayed again. It’s a surprising amout of planning and work to set up a key signing ceremony, and we’ve been working on a number of urgent scalability issues, so we haven’t been able to make the time for it. It’s definitely still on my radar, though! I’ll talk to the team about updating the ETA on that. Thanks for the ping!

3 Likes
7

I’ve been checking the upcoming feature every few days to see if we have ECDSA support yet.
With the power an intermediate certificate holds, the planning work is totally understandable.

Can we know by whom this new ECDSA will be signed? AFAIK, neither IdenTrust nor ISRG has ECC roots in any major vendor root lists, so I’m assuming it will be signed and cross-signed by ISRG (4096 RSA SHA256) and IdenTrust (2048 RSA SHA1)?

Thanks a lot.

8

Deciding how to structure the cross-signatures will be part of the planning for the key ceremony, but that will most likely be the plan.

9

Hopefully ISRG will generate an ECC root certificate in the same ceremony :grinning:

And while they're at it, perhapse generate Ed25519 and Ed448 keys as well, although I'm doubting there are stable implementations in the X.509 field yet. :neutral_face: And if the HSM supports them at all :stuck_out_tongue:

10

As edgy as we want to be, I’m sure there’s a lot going on to actually get a new root created and distributed. It would be pretty cool to have x25519 support though.

As for x25519, the intermediates could sign a x25519 leaf if it wants (correct me if I’m wrong please). google.com already has an x25519 certificate in Chrome, signed by an RSA intermediate. With openssh/openbsd already using ed25519, I’m pretty sure there are HSMs supporting it.

11

Offtopic: Euh, @Weird, x25519 is used for ECC Diffie-Hellman key exchange. That’s indeed supported in Chrome, but isn’t a certificate. I can’t find any Google certificate in my Chrome certificate store either. Neither is any of the Google Trust Services’ roots a Ed25519 curve. It isn’t allowed by the CA/B Forum BR too by the way :wink:

12

Right.
In Chrome, you will see the key exchange is x25519. I don’t think ssllabs test sees the same certs.

13

[quote=“Weird, post:12, topic:27940”]
In Chrome, you will see the key exchange is x25519.
[/quote]
Yes, that’s used for the Diffie-Hellman key exchange, the ECDHE-part of a cipher suite such as TLS_ECDHE_RSA_(…) or TLS_ECDHE_ECDSA_(…). Indeed, Chrome says things like “(…) a strong key exchange (ECDHE_ECDSA with X25519)”. A key exchange composed of two algorithms with, indeed, ECDSA, nót EdDSA :wink: ECDSA (and its current counterpart RSA) is the part which is based on the certificate. Both x25519 and Ed25519 use Curve25519, but both in just a little different way. (Curve25519 and x25519 are actually the same thing, just a different name for clarity sake. x... specifically for the DH algorith and Curve... for the general curve, which can be used for multiple purposes.) See the links for more info.

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.