In development of a web service, I can use self signed server certificate for testing under HTTPS. How can we make a client (possibly run in the same host, but maybe a different host) work with the service in HTTPS?

On Ubuntu 18.04, I try to run a gRPC service in ASP.NET Core. https://stackoverflow.com/a/59702094 says

On Ubuntu the standard mechanism would be:

  • dotnet dev-certs https -v to generate a self-signed cert
  • convert the generated cert in ~/.dotnet/corefx/cryptography/x509stores/my from pfx to pem using openssl pkcs12 -in <certname>.pfx -nokeys -out localhost.crt -nodes
  • copy localhost.crt to /usr/local/share/ca-certificates
  • trust the certificate using sudo update-ca-certificates
  • verify if the cert is copied to /etc/ssl/certs/localhost.pem (extension changes)
  • verify if it's trusted using openssl verify localhost.crt

Does it only mention about creating and self signing a server certificate for a service, but not setting up for a client? I heard that a browser will warn about self signed server certificates, so wondering how to prepare a web service client to handle self signed server certificates?

Can dotnet dev-certs https -v be replaced with some general command which doesn't depend on .NET Core? Note: dotnet dev-certs https -v actually doesn't work on Ubuntu, but only on Windows and Mac. See the link for workaround.


  • You might find that it's simpler to just get a free CA-signed certificate from Lets Encrypt (or a low-cost certificate from another CA), than to try to get your browser to recognize a self-signed certificate as trusted.
    – mti2935
    Feb 27, 2020 at 19:07
  • There is no generic way which applies to every possible client. It depends on the specific client, the OS, maybe the environment etc. And what you describe as "standard mechanism on ubuntu" isn't a standard mechanism either. It is one way which works for specific applications only. Feb 27, 2020 at 22:27

1 Answer 1


If you're just trying to get trusted certs for local Web development that browsers won't reject, this works pretty well:

create a directory called [www.mysecuredomain.com] (make that custom to your project)

paste the following into a file named host.conf inside the directory:


default_bits       = 2048
default_keyfile    = server.key
distinguished_name = req_distinguished_name
req_extensions     = req_ext
x509_extensions    = v3_ca


countryName                 = Country Name (2 letter code)
countryName_default         = US
stateOrProvinceName         = State or Province Name (full name)
stateOrProvinceName_default = [Your State Name Here]
localityName                = Locality Name (eg, city)
localityName_default        = [Your City Name Here]
organizationName            = Organization Name (eg, company)
organizationName_default    = [Your Org Name Here]
organizationalUnitName      = organizationalunit
organizationalUnitName_default = [ Your Org Unit Here ]
commonName                  = Common Name (e.g. server FQDN or YOUR name)
commonName_default          = [ www.mydevdomain.com ]
commonName_max              = 64


subjectAltName = @alt_names


subjectAltName = @alt_names

DNS.1   = [ www.mydevdomain.com ]

throw this in a shell file (example: create-trusted-cert.sh) above the directory you just created:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout "./$1/server.key" -out "./$1/server.crt" -config "./$1/host.conf"
certutil -d sql:$HOME/.pki/nssdb -D -n $1
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n "$1" -i "./$1/server.crt"
certutil -d sql:$HOME/.pki/nssdb -L | grep "$1"

type this at the commanline:

> ./create-trusted-cert.sh [www.mysecuredomain.com]

Be sure to modify the values in the directory, host.conf and command line args to fit your project.
Happy developing.

  • Thanks. Does your way work with web applications or web services developed under any framework in any language? Does your way work with gRPC services under ASP.NET Core (see my post)?
    – Tim
    Mar 3, 2020 at 21:01
  • Not 100% sure, but If those services rely on the OS for trust and/or don't reflexively reject self-signed certs, then I'd think yes. (EDIT: I could be wildly wrong though - I often am). What I do know is it works for locally signed certs where the client or framework relies on the OS for trust and doesn't reflexively reject. So for Firefox on Ubuntu, no. That client rejects all self-signed certs. But for Chrome, yes; Chrome is fine with a locally signed cert as long as it is added to nssdb. Mar 3, 2020 at 21:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .