feat(https): support using encrypted private key and pkcs12 (pfx) keystore

[Mastercuber]

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This PR introduces 2 new options when starting a HTTPS server:

1. Provide a certificate with encrypted private key
2. Provide a certificate stored in a PKCS12 (PFX) keystore. The keystore can have a password, but not the certificate in it!

The test certificate has been removed and a generate-cert.ts script is now generating the cert and a keystore before executing the test. In this context the already existing setup script was made global (see vitest config) to only get executed once.

Also a bunch of tests was introduced and the types.ts and cert.ts files got a bit refactored.

So now it's possible to pass the following combinations as https options:

https: true

https: {
  cert: 'path/to/cert.pem',
  key: 'path/to/key.pem'
}

https: {
  cert: '-----BEGIN CERTIFICATE----- ....',
  key: '-----BEGIN PRIVATE KEY----- ....' ||  '-----BEGIN RSA PRIVATE KEY----- .....'
}

https: {
  cert: '-----BEGIN CERTIFICATE----- ....',
  key: '-----BEGIN ENCRYPTED PRIVATE KEY----- .....',
  passphrase: 'cert-pw'
}

https: {
  cert: 'path/to/cert.pem',
  key: 'path/to/key.pem',
  passphrase: 'cert-pw'
}

https: {
  pfx: 'path/to/keystore.p12'
}

https: {
  pfx: 'path/to/keystore.p12',
  passphrase: 'store-pass'
}

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[pi0]

Hi dear @Mastercuber thanks for this nice PR looks so promising!

It might take little bit longer until i can make a proper review on your PR and merge it.

In the meantime, do you think you can refactor out https options normalization logic outof listhen.ts? 🙏🏼 This can improve core readability also reduce merge conflicts.

[Mastercuber]

Hi @pi0 😃
Just take your time. No hurry!

I will extract the normalization into _utils.ts or cert.ts, so that the HTTPOptions resolves to the https cert and key object.

[Mastercuber]

This was no big deal, so I refactored it now.

One notice while reviewing this PR:
The certificate signing goes one step to far. I realized it to late and though I will leave it in the PR.
With the signCertificate function it's also possible to sign a certificate with a CA cert WITH passphrase. This is not possible now, since no certificate for signing can be passed and also, perhaps, this is not wanted since listhen is an HTTP Listener and not a certificate generator.

Something other I noticed is, that node-forge seems to no longer get maintained. This could maybe get a problem, maybe not...

[Mastercuber]

Sorry for force pushing.. I got diverged branches.

Would the right solution have been to discard my commits through the github web interface - like suggested - and sync the fork with the upstream (both through web interface), then rebase the upstream's main branch locally and then just push?

I went an hard reset way now, involving patch files..

[pi0]

No worries. I have rebased it again.

[pi0]

Thanks 💯