Closed pepone closed 1 year ago
I think it's more effort than it's worth. These days certs are only good for a year (that's all browsers accept these days). If a user wants to do this kind of testing they should just copy the certs around.
IMO we shouldn't even ship a certs dir. The build script should just generate them. I'm pretty sure the dotnet
command can generate a set of self signed certs.
Another option is to package makecerts.py
as a pip package and explain how to use it in the README.md, I want to avoid copying makecerts.py
into each repository that needs SSL test certificates.
What are other projects doing?
aspnetcore seeems to include a bunch of certificates
$ find . -iname *.pfx
./src/DataProtection/DataProtection/test/TestFiles/TestCert1.pfx
./src/DataProtection/DataProtection/test/TestFiles/TestCert2.pfx
./src/DataProtection/Extensions/test/TestFiles/TestCert.pfx
./src/DataProtection/Extensions/test/TestFiles/TestCert2.pfx
./src/DataProtection/Extensions/test/TestFiles/TestCert3.pfx
./src/DataProtection/Extensions/test/TestFiles/TestCert3WithoutPrivateKey.pfx
./src/DataProtection/Extensions/test/TestFiles/TestCertWithoutPrivateKey.pfx
./src/DefaultBuilder/test/Microsoft.AspNetCore.FunctionalTests/testCert.pfx
./src/Identity/ApiAuthorization.IdentityServer/test/current.pfx
./src/Identity/ApiAuthorization.IdentityServer/test/expired.pfx
./src/Identity/ApiAuthorization.IdentityServer/test/future.pfx
./src/Identity/ApiAuthorization.IdentityServer/test/test.pfx
./src/Middleware/HttpsPolicy/sample/testCert.pfx
./src/Middleware/Rewrite/sample/testCert.pfx
./src/Middleware/WebSockets/test/ConformanceTests/AutobahnTestApp/TestResources/testCert.pfx
./src/Security/Authentication/Negotiate/test/Negotiate.FunctionalTest/negotiateAuthCert.pfx
./src/Security/Authentication/OpenIdConnect/samples/OpenIdConnectSample/compiler/resources/cert.pfx
./src/Security/Authentication/samples/SocialSample/compiler/resources/cert.pfx
./src/Security/Authentication/WsFederation/samples/WsFedSample/compiler/resources/cert.pfx
./src/Servers/IIS/tools/TestCert.pfx
./src/Shared/TestCertificates/aspnetdevcert.pfx
./src/Shared/TestCertificates/eku.client.pfx
./src/Shared/TestCertificates/eku.code_signing.pfx
./src/Shared/TestCertificates/eku.multiple_usages.pfx
./src/Shared/TestCertificates/eku.server.pfx
./src/Shared/TestCertificates/no_extensions.pfx
./src/Shared/TestCertificates/testCert.pfx
./src/SignalR/common/Shared/testCert.pfx
./src/SignalR/common/Shared/testCertECC.pfx
Doesn't seems to be a script to handle all the certificates, there are a few PowerShell scripts, but this are clearly no cross-platform
https://github.com/dotnet/aspnetcore/blob/main/src/DataProtection/CreateTestCert.ps1 https://github.com/dotnet/aspnetcore/blob/main/src/Servers/IIS/tools/UpdateIISExpressCertificate.ps1
https://github.com/dotnet/aspnetcore/blob/main/src/DataProtection/CreateTestCert.ps1
Looking of HttpClient or QuicConnection tests, they both get certificates using GetServerCertificate() which is defined here:
And the certificates appear to be generated by https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/libraries/Common/tests/System/Net/Prerequisites/Deployment/setup_certificates.ps1
The SslStream
tests appear to generate certificates directly from the tests: https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/libraries/System.Net.Security/tests/FunctionalTests/SslStreamNetworkStreamTest.cs
I think having a single solution that we can reuse across language mappings would be simpler, no need to create a separate script for rust
, swift
, or whatever language comes next.
But we also don't want to copy a large script like makercerts.py
to all repositories. My initial thought was to have icerpc-dev-certificates
repository, with the certificates and the makecerts.py
script, we can add this as a subtree to the other repositories.
The advantage is there is a single place to upgrade the script and certificates.
Another option is to package makecerts.py as a separate pip package icerpc-dev-certificates
and have the build script can run python -m icerpc-dev-certificates ./certs
or a similar command that creates the dev certificates if required.
Could we just have a private script (in dist-utils for now?) that we use to generate the certificates and copy over these certificates to each repository that need them? Or just instructions instead of a script? That's what gRPC does (no scripts, just instructions).
See:
The certs are valid for 10 years.
Assuming we can somehow create self-signed test certificates with a long validity (like 10 years), my preference would be to store these test certificates in icerpc.git:
/slice -- common Slice files
/test-certificates -- common test certificates
and then like for the Slice files, "copy" these test certificates to icerpc-csharp, icerpc-rust etc. via git subtree.
Exactly how we generate these long-lived test certificates is secondary.
I think a sub-tree maps to a single directory.
subtree gives you a tree. What's your concern?
Naturally, /slice and /test-certificates are two separate directories that get subtree"d" separately.
I didn't know you can subtree a single directory separately
I could be mistaken. In this case, our plan to use icerpc.git
to host the shared slice files doesn't work either. We'd need something like icerpc-slice.git
with the shared Slice files and not much else.
I don't think it makes sense to put these certs in the main iceprc
repo. I think we should try to find a good way to generate them when we need them, or just generate them manually and commit them to the repo.
I don't see a good need for a set of shared certs that are the same in every repo.
Are we ok with keeping the certificates and the makecerts.py
script in https://github.com/icerpc/icerpc-tools ?
Fine with me.
Actually, we could remove the certificates, it's not very useful to have them here.
I'm not sure that we need there repo at all right now TBO.
I'm not sure that we need there repo at all right now TBO.
I'm going to keep just the script there for now, there is always time to remove the repository if it turns out not to be useful.
The X509.2 certificates used by the tests and the examples, live in
certs
. It would be desirable for future mappings to share these certificates allowing users to test with the secure client, and server from different mappings. We can also use the same certificates for interop testing.A separate
icerpc-certs
, repository that can be used as asubmodule
orsubtree
by other repositories seems the right thing to do here.I still like submodules, but I'm fine with using a subtree if that is preferred, any preferences? any other options for sharing the certificates?