generate-certificate.sh with OpenSSL v3.3.0

[ghenry]

Hi all,

Looking to run the examples and obviously need to generate a cert, but getting:

./generate-certificate.sh 
Generate root CA key
Generate root CA certificate
Generate server key
Generate server certificate
Ignoring -days without -x509; not generating a certificate
Error checking extension section default
803BD14C3D7F0000:error:11000075:X509 V3 routines:v2i_GENERAL_NAME_ex:unsupported option:crypto/x509/v3_san.c:632:name=extendedKeyUsage
803BD14C3D7F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:crypto/x509/v3_conf.c:48:section=default, name=subjectAltName, value=@alt_names

This my local setup or something with OpenSSL v3?

Thanks.

[ghenry]

I'm upgrading to v3.3.1 now.

[ghenry]

Same. Thanks.

[djc]

On my macOS machine, I have installed OpenSSL 3.3.1 4 Jun 2024 (Library: OpenSSL 3.3.1 4 Jun 2024) from homebrew, but it works fine:

djc-2021 main scripts $ ./generate-certificate.sh 
Generate root CA key
Generate root CA certificate
Generate server key
Generate server certificate
Ignoring -days without -x509; not generating a certificate
Certificate request self-signature ok
subject=C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=foobar.com

[ghenry]

I'm using homebrew 3.3.1 too on Fedora Workstation 40. Weird.

[ghenry]

Solved it. extendedKeyUsage is only available on macOS:

https://github.com/search?q=repo%3Aopenssl%2Fopenssl%20extendedKeyUsage&type=code

Otherwise we default to:

https://github.com/openssl/openssl/blob/db2ac4f6ebd8f3d7b2a60882992fbea1269114e2/crypto/x509/v3_san.c#L617

Is there any reason this should macOS specific?

Thanks.

[ghenry]

Misread. Not solved.

[ghenry]

The reason I got to this script was that I was running the example with a commercial cert:

cargo run --example server -- 127.0.0.1:8000 --cert support.suretecsystems.com.crt --key support.suretecsystems.com.key 
   Compiling tokio-rustls v0.26.0 (/home/ghenry/RustroverProjects/tokio-rustls)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.78s
     Running `target/debug/examples/server '127.0.0.1:8000' --cert support.suretecsystems.com.crt --key support.suretecsystems.com.key`
thread 'main' panicked at examples/server.rs:41:10:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[ghenry]

Ah, figured it out. It writes all the files to ~/ NOT the directory I'm running the script from. I just saw all the files I've been looking for in my recent file list and went, "what?". Deleted them and all good every time.

We should update that to write out in ./ ??

[ghenry]

Even with those I get:

cargo run --example server -- 127.0.0.1:8000 --cert scripts/cert.pem --key scripts/server.key.pem 
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running `target/debug/examples/server '127.0.0.1:8000' --cert scripts/cert.pem --key scripts/server.key.pem`
thread 'main' panicked at examples/server.rs:41:10:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[ctz]

It seems examples/server.rs doesn't support key types other than RSA in PKCS#1 encoding. That seems less good, it should call private_key from rustls_pemfile rather than rsa_private_keys.

[cpu]

I think we can probably replace this whole generate-certificate.sh script with rcgen at this point and avoid both bash and openssl. I'd be in favour of that concurrent to fixing the rustls_pemfile usage.

[ghenry]

Yeah, was just reading that:

rustls_pemfile::pemfile::Item::Pkcs1Key
A DER-encoded plaintext RSA private key; as specified in PKCS #1/ RFC 3447
Appears as "RSA PRIVATE KEY" in PEM files.

[ghenry]

Is examples/server.rs still the best example code to read? I'm writing a Rust book for PragProg at the moment and the current chapter is about adding TLS support to my OSS project.

[cpu]

@ghenry For an async tokio project I suspect this repo's examples are best. More broadly there are a number of helpful/well-maintained examples in the core Rustls repo but they aren't using Tokio: https://github.com/rustls/rustls/tree/main/examples

[ghenry]

@ghenry For an async tokio project I suspect this repo's examples are best. More broadly there are a number of helpful/well-maintained examples in the core Rustls repo but they aren't using Tokio: https://github.com/rustls/rustls/tree/main/examples

Thanks. Yes, I was looking at the mio example, but was quite verbose (not a bad thing). I'll need to work up to that for the readers. Ultimately this all ends up in https://github.com/SentryPeer/SentryPeer/tree/main/sentrypeer_rust to add TLS support via Rustls to a C project.

[cpu]

Yes, I was looking at the mio example, but was quite verbose (not a bad thing). I'll need to work up to that for the readers.

Indeed, it is quite low-level.

Ultimately this all ends up in https://github.com/SentryPeer/SentryPeer/tree/main/sentrypeer_rust to add TLS support via Rustls to a C project.

Cool! In case you haven't seen it yet we also have rustls-ffi for offering native C bindings to the Rustls project. Depending on situation that might be helpful for your project as well.

[cpu]

That seems less good, it should call private_key from rustls_pemfile rather than rsa_private_keys.

https://github.com/rustls/tokio-rustls/pull/77

[ghenry]

Ultimately this all ends up in https://github.com/SentryPeer/SentryPeer/tree/main/sentrypeer_rust to add TLS support via Rustls to a C project.

Cool! In case you haven't seen it yet we also have rustls-ffi for offering native C bindings to the Rustls project. Depending on situation that might be helpful for your project as well.

Thanks! I'll definitely have a read of their techniques. Although, the book is about moving a C project to Rust and exploring which parts make sense to leave as-is because a Rust crate might be FFI-ing C or too new or too much unsafe etc. etc. :-)

Feel free to close this now. I'm really glad I spent time trying to get this working as that has improved it and introduced me to everyone here!

[cpu]

Although, the book is about moving a C project to Rust

Ahh ok :-) rustls-ffi would likely not be a good fit for that usecase then :+1:

Feel free to close this now. I'm really glad I spent time trying to get this working as that has improved it and introduced me to everyone here!

Thanks for filing the issue. I'll close this once https://github.com/rustls/tokio-rustls/pull/77 lands and then separately will look at replacing the crufty cert gen shell script with some new Rust.

Good luck with your book. Looking forward to reading it!

[ghenry]

Although, the book is about moving a C project to Rust

Ahh ok :-) rustls-ffi would likely not be a good fit for that usecase then 👍

Maybe by the end it could be the right way to go. That's the point of exploring all this :-)

Feel free to close this now. I'm really glad I spent time trying to get this working as that has improved it and introduced me to everyone here!

Thanks for filing the issue. I'll close this once #77 lands and then separately will look at replacing the crufty cert gen shell script with some new Rust.

Good luck with your book. Looking forward to reading it!

Thank you. Much appreciated!

[cpu]

I think we can probably replace this whole generate-certificate.sh script with rcgen at this point

Took a quick peek at this. The generate-certificates.sh script was carried over from the tokio-rs/tls repo when we split the Rustls code into this repo. It was initially added in https://github.com/tokio-rs/tls/pull/8 but has only ever been used for the tokio-native-tls crate's smoke tests. I think we should axe it in this repo.

However, we do have some hardcoded test certs in tests/ without an easy way to regenerate them (and they approach expiry). I'll gin something up with rcgen but I'd like to do some general tidying of the tests beforehand to reduce duplication and it'll have to wait for some spare time.

Closing this for now on the basis of the fix in #77

Thanks!