Provide access keys used for a SSL connection

I would like to use a ssl protected db with my application, which is deployed on Zeit Now. I am not sure how to get my p12 and my .pem file into the serverless function though.

I fount this issue: https://github.com/zeit/now/issues/749 , but I think it’s not possible that way, since we can’t combine env vars

[danhollick]

Just posting here to bump this back up the priority level.

This was quite a pain to hack around and will be a problem for almost anyone needing to use Prisma in production with a serverless environment.

I am using CloudSQL with SSL from Google Cloud for my database and Vercel (like OP) for my deployment provider. This is how I hacked around it for now:

I store both the server-ca.pem and client-identity.p12 in ENV variables (this gets tricky with the .p12 file and requires some base64 encoding) and then before the Prisma client is initialised I write them to the /tmp folder which is available to vercel deployments:

import { tmpdir } from 'os'
import fs from 'fs'

    fs.writeFile(
      `${tmpdir()}/server-ca.pem`,
      process.env.CLIENT_CERTIFICATE,
      err => {
        if (err) return console.log(err)
      }
    )

  fs.writeFile(
      `${tmpdir()}/client-identity.p12`,
      process.env.CLIENT_IDENTITY,
      //important to re-encode it correctly
      'base64',
      err => {
        if (err) return console.log(err)
      }
    )
...
global.prisma = new PrismaClient()

Then my database url for production looks like :

postgresql://USER:XXX@DBCONNECTION?&sslmode=require&sslaccept=accept_invalid_certs&sslidentity=/tmp/client-identity.p12&sslpassword=XXX&sslcert=/tmp/server-ca.pem

NOTE: Once you have encoded the client-identity.p12 into base64 it will exceed the size limit for ENVs in Vercel so you need to follow the guide mentioned here to encrypt it and then decrypt it before writing the file to disk.

For completeness here is my context.js where I initialise the Prisma client:

import { PrismaClient } from '@prisma/client'
import { tmpdir } from 'os'
import fs from 'fs'
import crypto from 'crypto'
// nextjs dev server reloads files on page navigation, so new Prisma Clients were being spawned everytime
let prisma

if (!global.prisma) {
  if (process.env.NODE_ENV !== 'development') {
    fs.writeFile(
      `${tmpdir()}/server-ca.pem`,
      process.env.CLIENT_CERTIFICATE,
      err => {
        if (err) return console.log(err)
      }
    )

    const algorithm = 'aes-128-cbc'
    const decipher = crypto.createDecipheriv(
      algorithm,
      process.env.CLIENT_IDENTITY_KEY,
      process.env.CLIENT_IDENTITY_IV
    )

    const getDecryptedSecret = () => {
      let decrypted = decipher.update(
        process.env.ENCRYPTED_CLIENT_IDENTITY,
        'base64',
        'utf8'
      )
      decrypted += decipher.final('utf8')
      return decrypted
    }

    fs.writeFile(
      `${tmpdir()}/client-identity.p12`,
      getDecryptedSecret(),
      'base64',
      err => {
        if (err) return console.log(err)
      }
    )
  }
  global.prisma = new PrismaClient({})
}

prisma = global.prisma

export default prisma

[matthewmueller]

Composing your .env is doable now. We didn’t implement it in the schema, but instead support .env template expansion: https://www.prisma.io/docs/concepts/components/prisma-schema#accessing-environment-variables-from-the-schema

So in your .env file:

SSL_CA="./path/to/ca.crt"
DATABASE_URL="postgresql://user:xxx@host?&sslmode=require&sslcert=${SERVER_CA}"

Then in production you can load a different .env or do it programmatically as @pantharshit00 suggested.

---

For the other part of the issue of accepting a certificate’s content as an environment variable. We probably won’t support this workflow directly, but recommend using the workaround @danhollick suggested. The main reason is that it’s easy enough to create a library in userland for handling this and environment variables have size limits.

If we get burned by /tmp not being writable in some serverless environment or enough people want this feature, we may revisit.

---

Closing, but happy to re-open if this workflow doesn’t work for you. Thanks!