MarkLeMerise

The following steps should (theoretically) only need to be once every few years (until the root CA certificate expires):

1. Run generate-certificate-authority.sh to generate a root Certificate Authority (CA) certificate. All future app-specific certs can "chain" from this.
2. This script will prompt you to create a pass phrase for your root CA certificate. Make sure to note this down (maybe in a nearby file; it's okay as plaintext since these are just development certificates) as you'll need it for future app-specific certificate generation.
3. Tell your OS/browser that it can trust this root CA. For example, on macOS, these certificate has to be added to the system keychain: sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" ca.pem.

Anytime you want to generate an app-specific certificate, run the following steps:

1. Tweak server.csr.cnf to use your particular domain, even if it's just localhost. Most importantly, the DNS.1 entry in v3.ext must match the `CN

MarkLeMerise

// ------------------------------------------
//          ______   ___  ______
//           )_   \ '-,) /   _(
//             )_  \_//_/  _(
//               )___  ___(
//                   ))
//                  ((
//                   ``-
//  HC SVNT DRACONES (et debitum technica)
// ------------------------------------------

MarkLeMerise

Your Azure AD instance must be configured to redirect any authentication request back to redirect.html upon successful authentication. redirect.html will handle sending the authenticated user to their intended destination.

For example, if an unauthenticated user navigates to "myapp.example/deep/link/to/somewhere/in/your/app", they will be taken through the normal Azure AD login process, sent to redirect.html, then properly routed to the deep link in your app.

This is what my deployable dist directory looks like: