add function to return a Certificate from DER format

[jiangshaoqi]

add "from_der" function in the Certificate implementation. This function can create a Certificate struct from DER encoded certificate.

Make sure the certificate match the format of x509-parser in rcgen, or the generated Certificate will be different.
A safe way of this usage is to load the DER certificate generated by rcgen itself.

[cpu]

Hi @jiangshaoqi, thanks for the contribution.

Can you speak more to your motivation for wanting this?

You can already construct CertificateParams directly from DER with the x509-parser feature enabled. It's not clear to me why you would want a Certificate from the DER given this gives you few capabilities beyond accessing the DER/PEM encoding (which you basically already have in-hand), or the CertificateParams which you can construct from the DER already. Am I overlooking a use-case?

[jiangshaoqi]

Hello @cpu , thank you for the reply.
I used this function in my project in the scenario: I am making a ResolvesServerCert to generate the fake end-entity certificates for my browser. I already have my own self-signed CA certificate, and have added it into browser's CA list.

In ResolvesServerCert, it requires the Certificate of my CA certificate, which has already been self signed and i need to directly load it as Certificate. If i read the certificate into CertificateParams, i will need to self_signed to generate the certificate.

Also, In my case, if i sign it again to get the Certificate, there will be some difference between my original certificate, because of x509 parser. for example, in my certificate:
X509v3 Basic Constraints: critical
CA: TRUE
the the new certificate from CertificateParams will automatically set CA: FALSE. (because of x509-parser implementation).

I also see people asking for: [https://github.com//issues/274]

What i did work for me, and i think it might be good for others. From your reply, i think i should also try use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

If it is same, please ignore my request

[jiangshaoqi]

I just checked: use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

It also works in my scenario, please ignore my request and have a good day!

[oscartbeaumont]

@jiangshaoqi I would be curious how you achieved the same certificate because I can't seem to reproduce it myself.

When I run the following code and the assertion fails:

letCertifiedKey{ cert, key_pair } = generate_simple_self_signed(vec!["abc".into()]).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

I kinda feel like this PR should be reopened and merged as a stop gap solution.

[blacktea1105]

@oscartbeaumont I found use KeyPair::generate_for(&rcgen::PKCS_ED25519) can work.

let key_pair = KeyPair::generate_for(&PKCS_ED25519).unwrap();let cert_params = CertificateParams::new(vec!["abc".into()]).unwrap();let cert = cert_params.self_signed(&key_pair).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

The problem is that the digital signatures are different between these two certificates.

I've found in the source code (sign signature) that the kind algorithm member within KeyPair is relevant. If the algorithm uses 'ECDSA' or 'RSA' (with the aws_lc_rs feature enabled), randomness is used as a parameter. KeyPair::generate() defaults to the 'ECDSA' algorithm.

However, KeyPair::from_pem likely doesn't have the previous randomness data (due to my unfamiliarity with cryptography, I'm unsure if randomness can be extracted from digital signatures. It seems KeyPair::from_pem doesn't take the digital signature as a parameter).

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

I'm wondering if it's possible to use:

1. the serde feature (although it might increase code complexity); or
2. if randomness can be extracted from the digital signature, perhaps the digital signature could be passed as an additional parameter to KeyPair::from_pem or KeyPair::from_der?

[djc]

The problem is that the digital signatures are different between these two certificates.

Why is this a problem?

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

Browsers don't support ED25519 certificates, unfortunately.

[blacktea1105]

Why is this a problem?

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

Browsers don't support ED25519 certificates, unfortunately.

Thanks for the clarification. Now I understand why browser still show certificate warning.

[djc]

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

It's still not obvious to me why that is a problem. Here's some example code that worked for me:

https://gist.github.com/djc/04d8d91fd5fe4ee6b7026373c5f247f4

(Not quite in a web context, but probably close enough.)

If you still believe there is a use case that rcgen doesn't cover, I suggest you open a new issue with a clear explanation of your use case rather than commenting on this confusingly-named closed PR.

[blacktea1105]

I understand. Thank you very much for your assistance.

[jiangshaoqi]

@oscartbeaumont For me it works only after the generating the cert with rustls. If it would work for you:
`let mut params =
CertificateParams::new(Vec::default()).expect("empty subject alt name can't produce error");
params.subject_alt_names = vec![
rcgen::SanType::DnsName(rcgen::Ia5String::try_from("localhost").unwrap()),
rcgen::SanType::IpAddress(std::net::IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)))
];

let (before, after) = validity_period();
params.is_ca = IsCa::Ca(BasicConstraints::Unconstrained);
params.distinguished_name.push(
DnType::CountryName,
PrintableString("CA".try_into().unwrap()),
);
params
.distinguished_name
.push(DnType::OrganizationName, "concordia shaoqi");
params.key_usages.push(KeyUsagePurpose::DigitalSignature);
params.key_usages.push(KeyUsagePurpose::KeyCertSign);
params.key_usages.push(KeyUsagePurpose::CrlSign);
params.not_before = before;
params.not_after = after;
let key_pair = KeyPair::generate().unwrap();
(params.self_signed(&key_pair).unwrap(), key_pair)`

[jiangshaoqi]

add "from_der" function in the Certificate implementation. This function can create a Certificate struct from DER encoded certificate.

Make sure the certificate match the format of x509-parser in rcgen, or the generated Certificate will be different.
A safe way of this usage is to load the DER certificate generated by rcgen itself.

[cpu]

Hi @jiangshaoqi, thanks for the contribution.

Can you speak more to your motivation for wanting this?

You can already construct CertificateParams directly from DER with the x509-parser feature enabled. It's not clear to me why you would want a Certificate from the DER given this gives you few capabilities beyond accessing the DER/PEM encoding (which you basically already have in-hand), or the CertificateParams which you can construct from the DER already. Am I overlooking a use-case?

[jiangshaoqi]

Hello @cpu , thank you for the reply.
I used this function in my project in the scenario: I am making a ResolvesServerCert to generate the fake end-entity certificates for my browser. I already have my own self-signed CA certificate, and have added it into browser's CA list.

In ResolvesServerCert, it requires the Certificate of my CA certificate, which has already been self signed and i need to directly load it as Certificate. If i read the certificate into CertificateParams, i will need to self_signed to generate the certificate.

Also, In my case, if i sign it again to get the Certificate, there will be some difference between my original certificate, because of x509 parser. for example, in my certificate:
X509v3 Basic Constraints: critical
CA: TRUE
the the new certificate from CertificateParams will automatically set CA: FALSE. (because of x509-parser implementation).

I also see people asking for: [https://github.com//issues/274]

What i did work for me, and i think it might be good for others. From your reply, i think i should also try use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

If it is same, please ignore my request

[jiangshaoqi]

I just checked: use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

It also works in my scenario, please ignore my request and have a good day!

[oscartbeaumont]

@jiangshaoqi I would be curious how you achieved the same certificate because I can't seem to reproduce it myself.

When I run the following code and the assertion fails:

letCertifiedKey{ cert, key_pair } = generate_simple_self_signed(vec!["abc".into()]).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

I kinda feel like this PR should be reopened and merged as a stop gap solution.

[blacktea1105]

@oscartbeaumont I found use KeyPair::generate_for(&rcgen::PKCS_ED25519) can work.

let key_pair = KeyPair::generate_for(&PKCS_ED25519).unwrap();let cert_params = CertificateParams::new(vec!["abc".into()]).unwrap();let cert = cert_params.self_signed(&key_pair).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

The problem is that the digital signatures are different between these two certificates.

I've found in the source code (sign signature) that the kind algorithm member within KeyPair is relevant. If the algorithm uses 'ECDSA' or 'RSA' (with the aws_lc_rs feature enabled), randomness is used as a parameter. KeyPair::generate() defaults to the 'ECDSA' algorithm.

However, KeyPair::from_pem likely doesn't have the previous randomness data (due to my unfamiliarity with cryptography, I'm unsure if randomness can be extracted from digital signatures. It seems KeyPair::from_pem doesn't take the digital signature as a parameter).

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

I'm wondering if it's possible to use:

1. the serde feature (although it might increase code complexity); or
2. if randomness can be extracted from the digital signature, perhaps the digital signature could be passed as an additional parameter to KeyPair::from_pem or KeyPair::from_der?

[djc]

The problem is that the digital signatures are different between these two certificates.

Why is this a problem?

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

Browsers don't support ED25519 certificates, unfortunately.

[blacktea1105]

Why is this a problem?

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

Browsers don't support ED25519 certificates, unfortunately.

Thanks for the clarification. Now I understand why browser still show certificate warning.

[djc]

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

It's still not obvious to me why that is a problem. Here's some example code that worked for me:

https://gist.github.com/djc/04d8d91fd5fe4ee6b7026373c5f247f4

(Not quite in a web context, but probably close enough.)

If you still believe there is a use case that rcgen doesn't cover, I suggest you open a new issue with a clear explanation of your use case rather than commenting on this confusingly-named closed PR.

[blacktea1105]

I understand. Thank you very much for your assistance.

[jiangshaoqi]

@oscartbeaumont For me it works only after the generating the cert with rustls. If it would work for you:
`let mut params =
CertificateParams::new(Vec::default()).expect("empty subject alt name can't produce error");
params.subject_alt_names = vec![
rcgen::SanType::DnsName(rcgen::Ia5String::try_from("localhost").unwrap()),
rcgen::SanType::IpAddress(std::net::IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)))
];

let (before, after) = validity_period();
params.is_ca = IsCa::Ca(BasicConstraints::Unconstrained);
params.distinguished_name.push(
DnType::CountryName,
PrintableString("CA".try_into().unwrap()),
);
params
.distinguished_name
.push(DnType::OrganizationName, "concordia shaoqi");
params.key_usages.push(KeyUsagePurpose::DigitalSignature);
params.key_usages.push(KeyUsagePurpose::KeyCertSign);
params.key_usages.push(KeyUsagePurpose::CrlSign);
params.not_before = before;
params.not_after = after;
let key_pair = KeyPair::generate().unwrap();
(params.self_signed(&key_pair).unwrap(), key_pair)`

[jiangshaoqi]

add "from_der" function in the Certificate implementation. This function can create a Certificate struct from DER encoded certificate.

Make sure the certificate match the format of x509-parser in rcgen, or the generated Certificate will be different.
A safe way of this usage is to load the DER certificate generated by rcgen itself.

[cpu]

Hi @jiangshaoqi, thanks for the contribution.

Can you speak more to your motivation for wanting this?

You can already construct CertificateParams directly from DER with the x509-parser feature enabled. It's not clear to me why you would want a Certificate from the DER given this gives you few capabilities beyond accessing the DER/PEM encoding (which you basically already have in-hand), or the CertificateParams which you can construct from the DER already. Am I overlooking a use-case?

[jiangshaoqi]

Hello @cpu , thank you for the reply.
I used this function in my project in the scenario: I am making a ResolvesServerCert to generate the fake end-entity certificates for my browser. I already have my own self-signed CA certificate, and have added it into browser's CA list.

In ResolvesServerCert, it requires the Certificate of my CA certificate, which has already been self signed and i need to directly load it as Certificate. If i read the certificate into CertificateParams, i will need to self_signed to generate the certificate.

Also, In my case, if i sign it again to get the Certificate, there will be some difference between my original certificate, because of x509 parser. for example, in my certificate:
X509v3 Basic Constraints: critical
CA: TRUE
the the new certificate from CertificateParams will automatically set CA: FALSE. (because of x509-parser implementation).

I also see people asking for: [https://github.com//issues/274]

What i did work for me, and i think it might be good for others. From your reply, i think i should also try use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

If it is same, please ignore my request

[jiangshaoqi]

I just checked: use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

It also works in my scenario, please ignore my request and have a good day!

[oscartbeaumont]

@jiangshaoqi I would be curious how you achieved the same certificate because I can't seem to reproduce it myself.

When I run the following code and the assertion fails:

letCertifiedKey{ cert, key_pair } = generate_simple_self_signed(vec!["abc".into()]).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

I kinda feel like this PR should be reopened and merged as a stop gap solution.

[blacktea1105]

@oscartbeaumont I found use KeyPair::generate_for(&rcgen::PKCS_ED25519) can work.

let key_pair = KeyPair::generate_for(&PKCS_ED25519).unwrap();let cert_params = CertificateParams::new(vec!["abc".into()]).unwrap();let cert = cert_params.self_signed(&key_pair).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

The problem is that the digital signatures are different between these two certificates.

I've found in the source code (sign signature) that the kind algorithm member within KeyPair is relevant. If the algorithm uses 'ECDSA' or 'RSA' (with the aws_lc_rs feature enabled), randomness is used as a parameter. KeyPair::generate() defaults to the 'ECDSA' algorithm.

However, KeyPair::from_pem likely doesn't have the previous randomness data (due to my unfamiliarity with cryptography, I'm unsure if randomness can be extracted from digital signatures. It seems KeyPair::from_pem doesn't take the digital signature as a parameter).

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

I'm wondering if it's possible to use:

1. the serde feature (although it might increase code complexity); or
2. if randomness can be extracted from the digital signature, perhaps the digital signature could be passed as an additional parameter to KeyPair::from_pem or KeyPair::from_der?

[djc]

The problem is that the digital signatures are different between these two certificates.

Why is this a problem?

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

Browsers don't support ED25519 certificates, unfortunately.

[blacktea1105]

Why is this a problem?

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

Browsers don't support ED25519 certificates, unfortunately.

Thanks for the clarification. Now I understand why browser still show certificate warning.

[djc]

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

It's still not obvious to me why that is a problem. Here's some example code that worked for me:

https://gist.github.com/djc/04d8d91fd5fe4ee6b7026373c5f247f4

(Not quite in a web context, but probably close enough.)

If you still believe there is a use case that rcgen doesn't cover, I suggest you open a new issue with a clear explanation of your use case rather than commenting on this confusingly-named closed PR.

[blacktea1105]

I understand. Thank you very much for your assistance.

[jiangshaoqi]

@oscartbeaumont For me it works only after the generating the cert with rustls. If it would work for you:
`let mut params =
CertificateParams::new(Vec::default()).expect("empty subject alt name can't produce error");
params.subject_alt_names = vec![
rcgen::SanType::DnsName(rcgen::Ia5String::try_from("localhost").unwrap()),
rcgen::SanType::IpAddress(std::net::IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)))
];

let (before, after) = validity_period();
params.is_ca = IsCa::Ca(BasicConstraints::Unconstrained);
params.distinguished_name.push(
DnType::CountryName,
PrintableString("CA".try_into().unwrap()),
);
params
.distinguished_name
.push(DnType::OrganizationName, "concordia shaoqi");
params.key_usages.push(KeyUsagePurpose::DigitalSignature);
params.key_usages.push(KeyUsagePurpose::KeyCertSign);
params.key_usages.push(KeyUsagePurpose::CrlSign);
params.not_before = before;
params.not_after = after;
let key_pair = KeyPair::generate().unwrap();
(params.self_signed(&key_pair).unwrap(), key_pair)`

[jiangshaoqi]

add "from_der" function in the Certificate implementation. This function can create a Certificate struct from DER encoded certificate.

Make sure the certificate match the format of x509-parser in rcgen, or the generated Certificate will be different.
A safe way of this usage is to load the DER certificate generated by rcgen itself.

[cpu]

Hi @jiangshaoqi, thanks for the contribution.

Can you speak more to your motivation for wanting this?

You can already construct CertificateParams directly from DER with the x509-parser feature enabled. It's not clear to me why you would want a Certificate from the DER given this gives you few capabilities beyond accessing the DER/PEM encoding (which you basically already have in-hand), or the CertificateParams which you can construct from the DER already. Am I overlooking a use-case?

[jiangshaoqi]

Hello @cpu , thank you for the reply.
I used this function in my project in the scenario: I am making a ResolvesServerCert to generate the fake end-entity certificates for my browser. I already have my own self-signed CA certificate, and have added it into browser's CA list.

In ResolvesServerCert, it requires the Certificate of my CA certificate, which has already been self signed and i need to directly load it as Certificate. If i read the certificate into CertificateParams, i will need to self_signed to generate the certificate.

Also, In my case, if i sign it again to get the Certificate, there will be some difference between my original certificate, because of x509 parser. for example, in my certificate:
X509v3 Basic Constraints: critical
CA: TRUE
the the new certificate from CertificateParams will automatically set CA: FALSE. (because of x509-parser implementation).

I also see people asking for: [https://github.com//issues/274]

What i did work for me, and i think it might be good for others. From your reply, i think i should also try use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

If it is same, please ignore my request

[jiangshaoqi]

I just checked: use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

It also works in my scenario, please ignore my request and have a good day!

[oscartbeaumont]

@jiangshaoqi I would be curious how you achieved the same certificate because I can't seem to reproduce it myself.

When I run the following code and the assertion fails:

letCertifiedKey{ cert, key_pair } = generate_simple_self_signed(vec!["abc".into()]).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

I kinda feel like this PR should be reopened and merged as a stop gap solution.

[blacktea1105]

@oscartbeaumont I found use KeyPair::generate_for(&rcgen::PKCS_ED25519) can work.

let key_pair = KeyPair::generate_for(&PKCS_ED25519).unwrap();let cert_params = CertificateParams::new(vec!["abc".into()]).unwrap();let cert = cert_params.self_signed(&key_pair).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

The problem is that the digital signatures are different between these two certificates.

I've found in the source code (sign signature) that the kind algorithm member within KeyPair is relevant. If the algorithm uses 'ECDSA' or 'RSA' (with the aws_lc_rs feature enabled), randomness is used as a parameter. KeyPair::generate() defaults to the 'ECDSA' algorithm.

However, KeyPair::from_pem likely doesn't have the previous randomness data (due to my unfamiliarity with cryptography, I'm unsure if randomness can be extracted from digital signatures. It seems KeyPair::from_pem doesn't take the digital signature as a parameter).

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

I'm wondering if it's possible to use:

1. the serde feature (although it might increase code complexity); or
2. if randomness can be extracted from the digital signature, perhaps the digital signature could be passed as an additional parameter to KeyPair::from_pem or KeyPair::from_der?

[djc]

The problem is that the digital signatures are different between these two certificates.

Why is this a problem?

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

Browsers don't support ED25519 certificates, unfortunately.

[blacktea1105]

Why is this a problem?

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

Browsers don't support ED25519 certificates, unfortunately.

Thanks for the clarification. Now I understand why browser still show certificate warning.

[djc]

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

It's still not obvious to me why that is a problem. Here's some example code that worked for me:

https://gist.github.com/djc/04d8d91fd5fe4ee6b7026373c5f247f4

(Not quite in a web context, but probably close enough.)

If you still believe there is a use case that rcgen doesn't cover, I suggest you open a new issue with a clear explanation of your use case rather than commenting on this confusingly-named closed PR.

[blacktea1105]

I understand. Thank you very much for your assistance.

[jiangshaoqi]

@oscartbeaumont For me it works only after the generating the cert with rustls. If it would work for you:
`let mut params =
CertificateParams::new(Vec::default()).expect("empty subject alt name can't produce error");
params.subject_alt_names = vec![
rcgen::SanType::DnsName(rcgen::Ia5String::try_from("localhost").unwrap()),
rcgen::SanType::IpAddress(std::net::IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)))
];

let (before, after) = validity_period();
params.is_ca = IsCa::Ca(BasicConstraints::Unconstrained);
params.distinguished_name.push(
DnType::CountryName,
PrintableString("CA".try_into().unwrap()),
);
params
.distinguished_name
.push(DnType::OrganizationName, "concordia shaoqi");
params.key_usages.push(KeyUsagePurpose::DigitalSignature);
params.key_usages.push(KeyUsagePurpose::KeyCertSign);
params.key_usages.push(KeyUsagePurpose::CrlSign);
params.not_before = before;
params.not_after = after;
let key_pair = KeyPair::generate().unwrap();
(params.self_signed(&key_pair).unwrap(), key_pair)`

[jiangshaoqi]

add "from_der" function in the Certificate implementation. This function can create a Certificate struct from DER encoded certificate.

Make sure the certificate match the format of x509-parser in rcgen, or the generated Certificate will be different.
A safe way of this usage is to load the DER certificate generated by rcgen itself.

[cpu]

Hi @jiangshaoqi, thanks for the contribution.

Can you speak more to your motivation for wanting this?

You can already construct CertificateParams directly from DER with the x509-parser feature enabled. It's not clear to me why you would want a Certificate from the DER given this gives you few capabilities beyond accessing the DER/PEM encoding (which you basically already have in-hand), or the CertificateParams which you can construct from the DER already. Am I overlooking a use-case?

[jiangshaoqi]

Hello @cpu , thank you for the reply.
I used this function in my project in the scenario: I am making a ResolvesServerCert to generate the fake end-entity certificates for my browser. I already have my own self-signed CA certificate, and have added it into browser's CA list.

In ResolvesServerCert, it requires the Certificate of my CA certificate, which has already been self signed and i need to directly load it as Certificate. If i read the certificate into CertificateParams, i will need to self_signed to generate the certificate.

Also, In my case, if i sign it again to get the Certificate, there will be some difference between my original certificate, because of x509 parser. for example, in my certificate:
X509v3 Basic Constraints: critical
CA: TRUE
the the new certificate from CertificateParams will automatically set CA: FALSE. (because of x509-parser implementation).

I also see people asking for: [https://github.com//issues/274]

What i did work for me, and i think it might be good for others. From your reply, i think i should also try use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

If it is same, please ignore my request

[jiangshaoqi]

I just checked: use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

It also works in my scenario, please ignore my request and have a good day!

[oscartbeaumont]

@jiangshaoqi I would be curious how you achieved the same certificate because I can't seem to reproduce it myself.

When I run the following code and the assertion fails:

letCertifiedKey{ cert, key_pair } = generate_simple_self_signed(vec!["abc".into()]).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

I kinda feel like this PR should be reopened and merged as a stop gap solution.

[blacktea1105]

@oscartbeaumont I found use KeyPair::generate_for(&rcgen::PKCS_ED25519) can work.

let key_pair = KeyPair::generate_for(&PKCS_ED25519).unwrap();let cert_params = CertificateParams::new(vec!["abc".into()]).unwrap();let cert = cert_params.self_signed(&key_pair).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

The problem is that the digital signatures are different between these two certificates.

I've found in the source code (sign signature) that the kind algorithm member within KeyPair is relevant. If the algorithm uses 'ECDSA' or 'RSA' (with the aws_lc_rs feature enabled), randomness is used as a parameter. KeyPair::generate() defaults to the 'ECDSA' algorithm.

However, KeyPair::from_pem likely doesn't have the previous randomness data (due to my unfamiliarity with cryptography, I'm unsure if randomness can be extracted from digital signatures. It seems KeyPair::from_pem doesn't take the digital signature as a parameter).

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

I'm wondering if it's possible to use:

1. the serde feature (although it might increase code complexity); or
2. if randomness can be extracted from the digital signature, perhaps the digital signature could be passed as an additional parameter to KeyPair::from_pem or KeyPair::from_der?

[djc]

The problem is that the digital signatures are different between these two certificates.

Why is this a problem?

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

Browsers don't support ED25519 certificates, unfortunately.

[blacktea1105]

Why is this a problem?

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

Browsers don't support ED25519 certificates, unfortunately.

Thanks for the clarification. Now I understand why browser still show certificate warning.

[djc]

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

It's still not obvious to me why that is a problem. Here's some example code that worked for me:

https://gist.github.com/djc/04d8d91fd5fe4ee6b7026373c5f247f4

(Not quite in a web context, but probably close enough.)

If you still believe there is a use case that rcgen doesn't cover, I suggest you open a new issue with a clear explanation of your use case rather than commenting on this confusingly-named closed PR.

[blacktea1105]

I understand. Thank you very much for your assistance.

[jiangshaoqi]

@oscartbeaumont For me it works only after the generating the cert with rustls. If it would work for you:
`let mut params =
CertificateParams::new(Vec::default()).expect("empty subject alt name can't produce error");
params.subject_alt_names = vec![
rcgen::SanType::DnsName(rcgen::Ia5String::try_from("localhost").unwrap()),
rcgen::SanType::IpAddress(std::net::IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)))
];

let (before, after) = validity_period();
params.is_ca = IsCa::Ca(BasicConstraints::Unconstrained);
params.distinguished_name.push(
DnType::CountryName,
PrintableString("CA".try_into().unwrap()),
);
params
.distinguished_name
.push(DnType::OrganizationName, "concordia shaoqi");
params.key_usages.push(KeyUsagePurpose::DigitalSignature);
params.key_usages.push(KeyUsagePurpose::KeyCertSign);
params.key_usages.push(KeyUsagePurpose::CrlSign);
params.not_before = before;
params.not_after = after;
let key_pair = KeyPair::generate().unwrap();
(params.self_signed(&key_pair).unwrap(), key_pair)`

[jiangshaoqi]

add "from_der" function in the Certificate implementation. This function can create a Certificate struct from DER encoded certificate.

Make sure the certificate match the format of x509-parser in rcgen, or the generated Certificate will be different.
A safe way of this usage is to load the DER certificate generated by rcgen itself.

[cpu]

Hi @jiangshaoqi, thanks for the contribution.

Can you speak more to your motivation for wanting this?

You can already construct CertificateParams directly from DER with the x509-parser feature enabled. It's not clear to me why you would want a Certificate from the DER given this gives you few capabilities beyond accessing the DER/PEM encoding (which you basically already have in-hand), or the CertificateParams which you can construct from the DER already. Am I overlooking a use-case?

[jiangshaoqi]

Hello @cpu , thank you for the reply.
I used this function in my project in the scenario: I am making a ResolvesServerCert to generate the fake end-entity certificates for my browser. I already have my own self-signed CA certificate, and have added it into browser's CA list.

In ResolvesServerCert, it requires the Certificate of my CA certificate, which has already been self signed and i need to directly load it as Certificate. If i read the certificate into CertificateParams, i will need to self_signed to generate the certificate.

Also, In my case, if i sign it again to get the Certificate, there will be some difference between my original certificate, because of x509 parser. for example, in my certificate:
X509v3 Basic Constraints: critical
CA: TRUE
the the new certificate from CertificateParams will automatically set CA: FALSE. (because of x509-parser implementation).

I also see people asking for: [https://github.com//issues/274]

What i did work for me, and i think it might be good for others. From your reply, i think i should also try use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

If it is same, please ignore my request

[jiangshaoqi]

I just checked: use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

It also works in my scenario, please ignore my request and have a good day!

[oscartbeaumont]

@jiangshaoqi I would be curious how you achieved the same certificate because I can't seem to reproduce it myself.

When I run the following code and the assertion fails:

letCertifiedKey{ cert, key_pair } = generate_simple_self_signed(vec!["abc".into()]).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

I kinda feel like this PR should be reopened and merged as a stop gap solution.

[blacktea1105]

@oscartbeaumont I found use KeyPair::generate_for(&rcgen::PKCS_ED25519) can work.

let key_pair = KeyPair::generate_for(&PKCS_ED25519).unwrap();let cert_params = CertificateParams::new(vec!["abc".into()]).unwrap();let cert = cert_params.self_signed(&key_pair).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

The problem is that the digital signatures are different between these two certificates.

I've found in the source code (sign signature) that the kind algorithm member within KeyPair is relevant. If the algorithm uses 'ECDSA' or 'RSA' (with the aws_lc_rs feature enabled), randomness is used as a parameter. KeyPair::generate() defaults to the 'ECDSA' algorithm.

However, KeyPair::from_pem likely doesn't have the previous randomness data (due to my unfamiliarity with cryptography, I'm unsure if randomness can be extracted from digital signatures. It seems KeyPair::from_pem doesn't take the digital signature as a parameter).

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

I'm wondering if it's possible to use:

1. the serde feature (although it might increase code complexity); or
2. if randomness can be extracted from the digital signature, perhaps the digital signature could be passed as an additional parameter to KeyPair::from_pem or KeyPair::from_der?

[djc]

The problem is that the digital signatures are different between these two certificates.

Why is this a problem?

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

Browsers don't support ED25519 certificates, unfortunately.

[blacktea1105]

Why is this a problem?

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

Browsers don't support ED25519 certificates, unfortunately.

Thanks for the clarification. Now I understand why browser still show certificate warning.

[djc]

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

It's still not obvious to me why that is a problem. Here's some example code that worked for me:

https://gist.github.com/djc/04d8d91fd5fe4ee6b7026373c5f247f4

(Not quite in a web context, but probably close enough.)

If you still believe there is a use case that rcgen doesn't cover, I suggest you open a new issue with a clear explanation of your use case rather than commenting on this confusingly-named closed PR.

[blacktea1105]

I understand. Thank you very much for your assistance.

[jiangshaoqi]

@oscartbeaumont For me it works only after the generating the cert with rustls. If it would work for you:
`let mut params =
CertificateParams::new(Vec::default()).expect("empty subject alt name can't produce error");
params.subject_alt_names = vec![
rcgen::SanType::DnsName(rcgen::Ia5String::try_from("localhost").unwrap()),
rcgen::SanType::IpAddress(std::net::IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)))
];

let (before, after) = validity_period();
params.is_ca = IsCa::Ca(BasicConstraints::Unconstrained);
params.distinguished_name.push(
DnType::CountryName,
PrintableString("CA".try_into().unwrap()),
);
params
.distinguished_name
.push(DnType::OrganizationName, "concordia shaoqi");
params.key_usages.push(KeyUsagePurpose::DigitalSignature);
params.key_usages.push(KeyUsagePurpose::KeyCertSign);
params.key_usages.push(KeyUsagePurpose::CrlSign);
params.not_before = before;
params.not_after = after;
let key_pair = KeyPair::generate().unwrap();
(params.self_signed(&key_pair).unwrap(), key_pair)`

[jiangshaoqi]

add "from_der" function in the Certificate implementation. This function can create a Certificate struct from DER encoded certificate.

Make sure the certificate match the format of x509-parser in rcgen, or the generated Certificate will be different.
A safe way of this usage is to load the DER certificate generated by rcgen itself.

[cpu]

Hi @jiangshaoqi, thanks for the contribution.

Can you speak more to your motivation for wanting this?

You can already construct CertificateParams directly from DER with the x509-parser feature enabled. It's not clear to me why you would want a Certificate from the DER given this gives you few capabilities beyond accessing the DER/PEM encoding (which you basically already have in-hand), or the CertificateParams which you can construct from the DER already. Am I overlooking a use-case?

[jiangshaoqi]

Hello @cpu , thank you for the reply.
I used this function in my project in the scenario: I am making a ResolvesServerCert to generate the fake end-entity certificates for my browser. I already have my own self-signed CA certificate, and have added it into browser's CA list.

In ResolvesServerCert, it requires the Certificate of my CA certificate, which has already been self signed and i need to directly load it as Certificate. If i read the certificate into CertificateParams, i will need to self_signed to generate the certificate.

Also, In my case, if i sign it again to get the Certificate, there will be some difference between my original certificate, because of x509 parser. for example, in my certificate:
X509v3 Basic Constraints: critical
CA: TRUE
the the new certificate from CertificateParams will automatically set CA: FALSE. (because of x509-parser implementation).

I also see people asking for: [https://github.com//issues/274]

What i did work for me, and i think it might be good for others. From your reply, i think i should also try use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

If it is same, please ignore my request

[jiangshaoqi]

I just checked: use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

It also works in my scenario, please ignore my request and have a good day!

[oscartbeaumont]

@jiangshaoqi I would be curious how you achieved the same certificate because I can't seem to reproduce it myself.

When I run the following code and the assertion fails:

letCertifiedKey{ cert, key_pair } = generate_simple_self_signed(vec!["abc".into()]).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

I kinda feel like this PR should be reopened and merged as a stop gap solution.

[blacktea1105]

@oscartbeaumont I found use KeyPair::generate_for(&rcgen::PKCS_ED25519) can work.

let key_pair = KeyPair::generate_for(&PKCS_ED25519).unwrap();let cert_params = CertificateParams::new(vec!["abc".into()]).unwrap();let cert = cert_params.self_signed(&key_pair).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

The problem is that the digital signatures are different between these two certificates.

I've found in the source code (sign signature) that the kind algorithm member within KeyPair is relevant. If the algorithm uses 'ECDSA' or 'RSA' (with the aws_lc_rs feature enabled), randomness is used as a parameter. KeyPair::generate() defaults to the 'ECDSA' algorithm.

However, KeyPair::from_pem likely doesn't have the previous randomness data (due to my unfamiliarity with cryptography, I'm unsure if randomness can be extracted from digital signatures. It seems KeyPair::from_pem doesn't take the digital signature as a parameter).

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

I'm wondering if it's possible to use:

1. the serde feature (although it might increase code complexity); or
2. if randomness can be extracted from the digital signature, perhaps the digital signature could be passed as an additional parameter to KeyPair::from_pem or KeyPair::from_der?

[djc]

The problem is that the digital signatures are different between these two certificates.

Why is this a problem?

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

Browsers don't support ED25519 certificates, unfortunately.

[blacktea1105]

Why is this a problem?

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

Browsers don't support ED25519 certificates, unfortunately.

Thanks for the clarification. Now I understand why browser still show certificate warning.

[djc]

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

It's still not obvious to me why that is a problem. Here's some example code that worked for me:

https://gist.github.com/djc/04d8d91fd5fe4ee6b7026373c5f247f4

(Not quite in a web context, but probably close enough.)

If you still believe there is a use case that rcgen doesn't cover, I suggest you open a new issue with a clear explanation of your use case rather than commenting on this confusingly-named closed PR.

[blacktea1105]

I understand. Thank you very much for your assistance.

[jiangshaoqi]

@oscartbeaumont For me it works only after the generating the cert with rustls. If it would work for you:
`let mut params =
CertificateParams::new(Vec::default()).expect("empty subject alt name can't produce error");
params.subject_alt_names = vec![
rcgen::SanType::DnsName(rcgen::Ia5String::try_from("localhost").unwrap()),
rcgen::SanType::IpAddress(std::net::IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)))
];

let (before, after) = validity_period();
params.is_ca = IsCa::Ca(BasicConstraints::Unconstrained);
params.distinguished_name.push(
DnType::CountryName,
PrintableString("CA".try_into().unwrap()),
);
params
.distinguished_name
.push(DnType::OrganizationName, "concordia shaoqi");
params.key_usages.push(KeyUsagePurpose::DigitalSignature);
params.key_usages.push(KeyUsagePurpose::KeyCertSign);
params.key_usages.push(KeyUsagePurpose::CrlSign);
params.not_before = before;
params.not_after = after;
let key_pair = KeyPair::generate().unwrap();
(params.self_signed(&key_pair).unwrap(), key_pair)`

[jiangshaoqi]

add "from_der" function in the Certificate implementation. This function can create a Certificate struct from DER encoded certificate.

Make sure the certificate match the format of x509-parser in rcgen, or the generated Certificate will be different.
A safe way of this usage is to load the DER certificate generated by rcgen itself.

[cpu]

Hi @jiangshaoqi, thanks for the contribution.

Can you speak more to your motivation for wanting this?

You can already construct CertificateParams directly from DER with the x509-parser feature enabled. It's not clear to me why you would want a Certificate from the DER given this gives you few capabilities beyond accessing the DER/PEM encoding (which you basically already have in-hand), or the CertificateParams which you can construct from the DER already. Am I overlooking a use-case?

[jiangshaoqi]

Hello @cpu , thank you for the reply.
I used this function in my project in the scenario: I am making a ResolvesServerCert to generate the fake end-entity certificates for my browser. I already have my own self-signed CA certificate, and have added it into browser's CA list.

In ResolvesServerCert, it requires the Certificate of my CA certificate, which has already been self signed and i need to directly load it as Certificate. If i read the certificate into CertificateParams, i will need to self_signed to generate the certificate.

Also, In my case, if i sign it again to get the Certificate, there will be some difference between my original certificate, because of x509 parser. for example, in my certificate:
X509v3 Basic Constraints: critical
CA: TRUE
the the new certificate from CertificateParams will automatically set CA: FALSE. (because of x509-parser implementation).

I also see people asking for: [https://github.com//issues/274]

What i did work for me, and i think it might be good for others. From your reply, i think i should also try use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

If it is same, please ignore my request

[jiangshaoqi]

I just checked: use rcgen generate a CA certificate DER, get its CertificateParams, do self_signed on it, and check if the new self-signed certificate is the same as the original CA certificate.

It also works in my scenario, please ignore my request and have a good day!

[oscartbeaumont]

@jiangshaoqi I would be curious how you achieved the same certificate because I can't seem to reproduce it myself.

When I run the following code and the assertion fails:

letCertifiedKey{ cert, key_pair } = generate_simple_self_signed(vec!["abc".into()]).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

I kinda feel like this PR should be reopened and merged as a stop gap solution.

[blacktea1105]

@oscartbeaumont I found use KeyPair::generate_for(&rcgen::PKCS_ED25519) can work.

let key_pair = KeyPair::generate_for(&PKCS_ED25519).unwrap();let cert_params = CertificateParams::new(vec!["abc".into()]).unwrap();let cert = cert_params.self_signed(&key_pair).unwrap();let before = cert.pem();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());let key_pair = rcgen::KeyPair::from_pem(&key_pair.serialize_pem()).unwrap();let cert = CertificateParams::from_ca_cert_der(&cert.try_into().unwrap()).unwrap().self_signed(&key_pair).unwrap();println!("{:?}", cert.pem());println!("{:?}\n\n\n", key_pair.serialize_pem());assert_eq!(before, cert.pem());

The problem is that the digital signatures are different between these two certificates.

I've found in the source code (sign signature) that the kind algorithm member within KeyPair is relevant. If the algorithm uses 'ECDSA' or 'RSA' (with the aws_lc_rs feature enabled), randomness is used as a parameter. KeyPair::generate() defaults to the 'ECDSA' algorithm.

However, KeyPair::from_pem likely doesn't have the previous randomness data (due to my unfamiliarity with cryptography, I'm unsure if randomness can be extracted from digital signatures. It seems KeyPair::from_pem doesn't take the digital signature as a parameter).

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

I'm wondering if it's possible to use:

1. the serde feature (although it might increase code complexity); or
2. if randomness can be extracted from the digital signature, perhaps the digital signature could be passed as an additional parameter to KeyPair::from_pem or KeyPair::from_der?

[djc]

The problem is that the digital signatures are different between these two certificates.

Why is this a problem?

Testing shows that KeyPair::generate_for(&rcgen::PKCS_ED25519) works, but I'm unsure about its security implications (I don't know if this algorithm only handles digital signatures or if it's also used for generating the certificate's public key). It should be fine for local development, though, right?

Browsers don't support ED25519 certificates, unfortunately.

[blacktea1105]

Why is this a problem?

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

Browsers don't support ED25519 certificates, unfortunately.

Thanks for the clarification. Now I understand why browser still show certificate warning.

[djc]

My scenario involves generating a root CA certificate, storing it in a file or database (and Adding to the operating system's trusted root store), and later restoring it to issue leaf certificates.

For me, the problem is the fingerprint of a restored root CA certificate does not match the original.

It's still not obvious to me why that is a problem. Here's some example code that worked for me:

https://gist.github.com/djc/04d8d91fd5fe4ee6b7026373c5f247f4

(Not quite in a web context, but probably close enough.)

If you still believe there is a use case that rcgen doesn't cover, I suggest you open a new issue with a clear explanation of your use case rather than commenting on this confusingly-named closed PR.

[blacktea1105]

I understand. Thank you very much for your assistance.

[jiangshaoqi]

@oscartbeaumont For me it works only after the generating the cert with rustls. If it would work for you:
`let mut params =
CertificateParams::new(Vec::default()).expect("empty subject alt name can't produce error");
params.subject_alt_names = vec![
rcgen::SanType::DnsName(rcgen::Ia5String::try_from("localhost").unwrap()),
rcgen::SanType::IpAddress(std::net::IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)))
];

let (before, after) = validity_period();
params.is_ca = IsCa::Ca(BasicConstraints::Unconstrained);
params.distinguished_name.push(
DnType::CountryName,
PrintableString("CA".try_into().unwrap()),
);
params
.distinguished_name
.push(DnType::OrganizationName, "concordia shaoqi");
params.key_usages.push(KeyUsagePurpose::DigitalSignature);
params.key_usages.push(KeyUsagePurpose::KeyCertSign);
params.key_usages.push(KeyUsagePurpose::CrlSign);
params.not_before = before;
params.not_after = after;
let key_pair = KeyPair::generate().unwrap();
(params.self_signed(&key_pair).unwrap(), key_pair)`