Creating Your Own SSL Certificate Authority (and Dumping Self Signed Certs)

March 1, 2012 75 Comments

Jan 11th, 2016: New Year! Also, there was a comment below about adding -sha256 to the signing (both self-signed and CSR signing) since browsers are starting to reject SHA1. Added (I ran through a test, it worked out for me at least).

November 18th, 2015: Oops! A few have mentioned additional errors that I missed. Fixed.

July 11th, 2015: There were a few bugs in this article that went unfixed for a while. They’ve been fixed.

SSL (or TLS if you want to be super totally correct) gives us many things (despite many of the recent shortcomings).

  • Privacy (stop looking at my password)
  • Integrity (data has not been altered in flight)
  • Trust (you are who you say you are)

All three of those are needed when you’re buying stuff from say, Amazon (damn you, Amazon Prime!). But we also use SSL for web user interfaces and other GUIs when  administering devices in our control. When a website gets an SSL certificate, they typically purchase one from a major certificate authority such as DigiCert, Symantec (they bought Verisign’s registrar business), or if you like the murder of elephants and freedom, GoDaddy.  They range from around $12 USD a year to several hundred, depending on the company and level of trust. The benefit that these certificate authorities provide is a chain of trust. Your browser trusts them, they trust a website, therefore your browser trusts the website (check my article on SSL trust, which contains the best SSL diagram ever conceived).

Your devices, on the other hand, the ones you configure and only your organization accesses, don’t need that trust chain built upon the public infrastrucuture. For one, it could get really expensive buying an SSL certificate for each device you control. And secondly, you set the devices up, so you don’t really need that level of trust. So web user interfaces (and other SSL-based interfaces) are almost always protected with self-signed certificates. They’re easy to create, and they’re free. They also provide you with the privacy that comes with encryption, although they don’t do anything about trust. Which is why when you connect to a device with a self-signed certificate, you get one of these: So you have the choice, buy an overpriced SSL certificate from a CA (certificate authority), or get those errors. Well, there’s a third option, one where you can create a private certificate authority, and setting it up is absolutely free.

OpenSSL

OpenSSL is a free utility that comes with most installations of MacOS X, Linux, the *BSDs, and Unixes. You can also download a binary copy to run on your Windows installation. And OpenSSL is all you need to create your own private certificate authority. The process for creating your own certificate authority is pretty straight forward:

  1. Create a private key
  2. Self-sign
  3. Install root CA on your various workstations
Once you do that, every device that you manage via HTTPS just needs to have its own certificate created with the following steps:
  1. Create CSR for device
  2. Sign CSR with root CA key
You can have your own private CA setup in less than an hour. And here’s how to do it.

Create the Root Certificate (Done Once)

Creating the root certificate is easy and can be done quickly. Once you do these steps, you’ll end up with a root SSL certificate that you’ll install on all of your desktops, and a private key you’ll use to sign the certificates that get installed on your various devices.

Create the Root Key

The first step is to create the private root key which only takes one step. In the example below, I’m creating a 2048 bit key:

openssl genrsa -out rootCA.key 2048

The standard key sizes today are 1024, 2048, and to a much lesser extent, 4096. I go with 2048, which is what most people use now. 4096 is usually overkill (and 4096 key length is 5 times more computationally intensive than 2048), and people are transitioning away from 1024. Important note: Keep this private key very private. This is the basis of all trust for your certificates, and if someone gets a hold of it, they can generate certificates that your browser will accept. You can also create a key that is password protected by adding -des3:

openssl genrsa -des3 -out rootCA.key 2048

You’ll be prompted to give a password, and from then on you’ll be challenged password every time you use the key. Of course, if you forget the password, you’ll have to do all of this all over again.

The next step is to self-sign this certificate.

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

This will start an interactive script which will ask you for various bits of information. Fill it out as you see fit.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Oregon
Locality Name (eg, city) []:Portland
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Overlords
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:Data Center Overlords
Email Address []:none@none.com

Once done, this will create an SSL certificate called rootCA.pem, signed by itself, valid for 1024 days, and it will act as our root certificate. The interesting thing about traditional certificate authorities is that root certificate is also self-signed. But before you can start your own certificate authority, remember the trick is getting those certs in  every browser in the entire world.

Install Root Certificate Into Workstations

For you laptops/desktops/workstations, you’ll need to install the root certificate into your trusted certificate repositories. This can get a little tricky. Some browsers use the default operating system repository. For instance, in Windows both IE and Chrome use the default certificate management.  Go to IE, Internet Options, go to the Content tab, then hit the Certificates button. In Chrome going to Options and Under The Hood, and Manage certificates. They both take you to the same place, the Windows certificate repository. You’ll want to install the root CA certificate (not the key) under the Trusted Root Certificate Authorities tab. However, in Windows Firefox has its own certificate repository, so if you use IE or Chrome as well as Firefox, you’ll have to install the root certificate into both the Windows repository and the Firefox repository. In a Mac, Safari, Firefox, and Chrome all use the Mac OS X certificate management system, so you just have to install it once on a Mac. With Linux, I believe it’s on a browser-per-browser basis.

Create A Certificate (Done Once Per Device)

Every device that you wish to install a trusted certificate will need to go through this process. First, just like with the root CA step, you’ll need to create a private key (different from the root CA).

openssl genrsa -out device.key 2048

Once the key is created, you’ll generate the certificate signing request.

openssl req -new -key device.key -out device.csr

You’ll be asked various questions (Country, State/Province, etc.). Answer them how you see fit. The important question to answer though is common-name.

Common Name (eg, YOUR name) []: 10.0.0.1

Whatever you see in the address field in your browser when you go to your device must be what you put under common name, even if it’s an IP address.  Yes, even an IP (IPv4 or IPv6) address works under common name. If it doesn’t match, even a properly signed certificate will not validate correctly and you’ll get the “cannot verify authenticity” error. Once that’s done, you’ll sign the CSR, which requires the CA root key.

openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days 500 -sha256

This creates a signed certificate called device.crt which is valid for 500 days (you can adjust the number of days of course, although it doesn’t make sense to have a certificate that lasts longer than the root certificate). The next step is to take the key and the certificate and install them in your device. Most network devices that are controlled via HTTPS have some mechanism for you to install. For example, I’m running F5’s LTM VE (virtual edition) as a VM on my ESXi 4 host. Log into F5’s web GUI (and should be the last time you’re greeted by the warning), and go to System, Device Certificates, and Device Certificate. In the drop down select Certificate and Key, and either past the contents of the key and certificate file, or you can upload them from your workstation.

After that, all you need to do is close your browser and hit the GUI site again. If you did it right, you’ll see no warning and a nice greenness in your address bar.

And speaking of VMware, you know that annoying message you always get when connecting to an ESXi host?

You can get rid of that by creating a key and certificate for your ESXi server and installing them as /etc/vmware/ssl/rui.crt and /etc/vmware/ssl/rui.key.

Filed under Load Balancing, Security, Virtualization, VMware

75 Responses to Creating Your Own SSL Certificate Authority (and Dumping Self Signed Certs)

  1. Awfki (@Awfki) says:
    March 1, 2012 at 7:27 pm

    Thank you for this. I’ve wanted to do this for quite a while but never bothered to look into what was needed.

    Also, I think “convinced” in “best SSL diagram ever convinced” was meant to be “conceived”. And yes, it is an awesome diagram.

    Reply
  2. Robert Sander says:
    March 4, 2012 at 10:03 am

    If you do not want to remember all the openssl command line arguments you could use a GUI such as http://xca.sourceforge.net/

    Reply
  3. gillespiem says:
    July 31, 2012 at 12:20 pm

    Good article (and great graphics), but the title is misleading.

    In no way does this dump self-signed certs as “(and Dumping Self Signed Certs)” claims – by definition a self-signed cert is “signed by the same entity whose identity it certifies”.

    You’re simply installing a root certificate soas to prevent clients from prompting you to acknowledge the certificate isn’t verified. It’s still very helpful, but it’s not dumping self-signed certs in any form.

    Reply
  4. j says:
    April 9, 2013 at 6:11 pm

    The next step is to self-sign this certificate.

    openssl req -x509 -new -nodes -key root.key -days 1024 -out rootCA.pem

    …did you mean rootCA.key?

    anyways this looks great, look forward to giving it a try

    Reply
  5. Neddage says:
    April 10, 2013 at 1:14 pm

    Good article. What’s the procedure when the root CA expires? Do you need to update all the other servers certificates or is there a shortcut? Or should you just give the root CA a lot longer before it expires, say 5 years?

    Reply
    • tonybourke says:
      April 10, 2013 at 1:15 pm

      Yeah, if the root expires, everything needs to be updated. That’s why if you look at root certificates in your operating system, they usually expire in 10-30 years.

      Reply
  6. Joe says:
    May 8, 2013 at 5:45 am

    What do you to update the rootCA bit size from 1024 to 2048? Do you reissue or can you just update the bit size?
    Thanks
    Joe

    Reply
    • dthompson says:
      January 10, 2014 at 7:19 pm

      The example is already 2048 bits for both root and “device”. But if you already have 1024 and want to change to 2048, which is a good idea, yes you must generate new keys and new certs. You can use the same name for the device or other end-entity certs (unless you WANT to change) but you should use a different name for the root cert to prevent a verifier from getting confused about which root is the right one and giving security errors that 99.99% of users won’t understand. (Even getting “root not found” many users won’t understand, but at least it points them in the right direction.)

      Reply

  7. Pingback: Confluence: ELSTER

  8. Pingback: Confluence: ELSTER

  9. Morris Mojo Jones (@mojo_la) says:
    July 29, 2013 at 10:18 am

    Here’s a tip: If you create a CA, don’t store the private key on a github repository.

    If I have a group of machines at work that will accept any device certificates signed by my CA, I don’t want someone using that CA key to potentially sign a proxy certificate or some other spoof.

    Reply
  10. Julius says:
    October 1, 2013 at 4:12 pm

    A little improved security, adapted to post-Snowden knowledge:
    – Install the absolute latest version of openssl (bypass apt or yum, use source..).
    – Fine commands to use instead of the two mentioned in your article:

    # openssl genrsa -out /root/rootCA.key 4096 -aes-256-cbc

    # openssl req -x509 -new -nodes -key /root/rootCA.key -days 3650 -out rootCA.pem -config /etc/ssl/openssl.cnf

    And you can edit the openssl.cnf defaults under [ req_distinguished_name ] to save time..

    Reply
  11. Alex says:
    October 11, 2013 at 10:23 am

    Good article, I am just missing or not understanding something.

    I am in a client server situation.
    I guess I put the rootCA.pem on the server and the device.crt on the client but that doesnt seem enough to me.
    Dont I need to create a server certificate, generate a public part, and put that public part in the client?
    If yes, how do I generate that?

    Thanks
    Alex
    But what do I put on the client app?

    Reply
    • ychaouche says:
      October 21, 2015 at 5:51 am

      If I understood correctly, nothing is to be installed on the client (the browsers) except the root certificate.

      To recap :
      1. You need an SSL key for your server
      2. The SSL key must be signed by a certificate authority
      3. You have two choices : a) buy a certificate by already existing authorities like Verisign or b) become an authority yourself. The article describes b)
      4. So you create what’s called a root certificate. A root certificate is a certificate that belongs to the top node of the trust hierarchy.
      5. Next, you create certificates for any of your servers (referred to as devices in this article) that need / want to have an SSL encryption (HTTPS URLs or mail servers with TLS encryption)
      6. Sign every single certificate with the root certificate you created at step 4.
      7. Deploy the certificates to their belongers (your HTTPS servers or mail servers)
      8. When you browse to these servers you will still get an SSL error because your servers’ certificates are authenticated by a certificate authority that your browser doesn’t know. So step 9
      9. is to install the root certificate in every browser that needs to access your servers, that way browsers will trust the certificates issued (signed) by that root certificate you’ve created.

      Mistakes, if any, are mine.

      Reply
      • Edd says:
        February 22, 2016 at 8:17 am

        How to install the root CA on the browsers? is necesary did the 8 steps before i can install the rootCA in the browsers?

    • Alan says:
      January 14, 2016 at 8:33 am

      I am replying directly to this post, as ychaouche’s response is still slightly ambiguous.

      The rootCA.pem file is installed in the browser. That allows it to recognise the response made by the server using the device.crt file.

      You install both the device.key file (the private key) and the device.crt file (the public key signed by the rootCA) on the server. Depends what server you have where you put the files but they are normally called ssl_certificate and ssl_certificate_key (thats the nginx directives) or something like that for apache. nodejs(https) uses a cert object {key: xxx cert: yyy} where you read the filecontents of the key and certiciate and load them into the strings xxx and yyy.

      Reply
  12. Brett Wolmarans (@bwolmarans) says:
    November 17, 2013 at 6:46 pm

    Simply the best and most straightforward article on the interwebs on this overly complex subject. Thank you.

    Reply
  13. Attila Lendvai says:
    November 26, 2013 at 10:24 pm

    -des3 must come earlier, otherwise it’s ignored. at least on my Debian version (OpenSSL 1.0.1e 11 Feb 2013) it is.

    openssl genrsa -des3 -out rootCA.key 2048

    Reply
    • Attila Lendvai says:
      December 2, 2013 at 1:38 am

      FYI, this is what i ended up with (note the various encryption and hash choices):

      the ca itself:
      ————–
      CA_NAME=rootCA-FooBar
      openssl genrsa -aes256 -out $CA_NAME.key 4096
      openssl req -x509 -sha512 -new -nodes -key $CA_NAME.key -days 65000 -out $CA_NAME.pem

      a site certificate:
      ————————–
      FQDN=foobar.dyndns.org
      openssl genrsa -out $FQDN.key 2048
      openssl req -sha512 -new -key $FQDN.key -out $FQDN.csr
      openssl x509 -sha512 -req -in $FQDN.csr -CA $CA_NAME.pem -CAkey $CA_NAME.key -CAcreateserial -out $FQDN.crt -days 65000

      install the root ca into a linux:
      —————————–
      cp rootCA.pem /usr/local/share/ca-certificates/rootCA.crt # with .crt extension!!!
      update-ca-certificates

      Reply
      • dthompson says:
        January 10, 2014 at 7:45 pm

        Yes, -des3 (or another cipher like -aes128) must come before the bitsize on genrsa; it may be before or after -out file.

        OTOH, for now I wouldn’t recommend -days 65000. I’m pretty sure there are still fielded systems checking cert times using 32-bit time_t and getting Y2038 bugs; that means about 8700 days from now (and going down steadily). Also, unfortunately, not all Linux distros, versions, or packages put openssl’s default store in the same place. Use ‘openssl version -d’ (or -a) to see where yours is. And I’m not sure they all have update-ca-certificates; you may have to run c_rehash yourself.

  14. Pingback: cephalin

  15. Jibran Bisharat (@via_jibran) says:
    March 17, 2015 at 1:51 pm

    Hi. Does this process work for wildcards? Or do I have to create a new set of certificates for each sub-domain. Ideally, I’d create one for each domain. Thx.

    Reply

  16. Pingback: Confluence: Technische Dienst

  17. Pingback: Skapa ett självsignerat certifikat till Synology Diskstation med OpenSSL | Jonatan Hilmarch

  18. Pingback: AFNetworking problems with TLS Verification of a self signed server root CA - BlogoSfera

  19. Gareth says:
    September 15, 2015 at 12:29 am

    hi. regarding Deprecation of Internal Server Names and Reserved IP Addresses –

    Any idea? but we have hotspots that require a private IP and the controller can hold a self-signed CA cert that is used with the SSL HTML handshake (common name = private IP), between client and access point, but, we don’t/can’t load the CA cert onto joe public and currently they get a warning message, will they still be able to negate the warning after next years deadline date?

    Reply
  20. Sean says:
    January 11, 2016 at 1:05 pm

    Add -sha256 to signing commands to create certificates with SHA256 signed certificates so browsers won’t reject them. SHA1 deprecated.

    Reply
  21. BP SF says:
    February 5, 2016 at 11:10 am

    This totally worked! I’m seriously super stoked… thanks a ton!

    Reply
  22. Edd says:
    February 22, 2016 at 8:59 am

    how i can install the root CA in a browser on a Windows machine.???

    Reply
  23. Jeff says:
    February 22, 2016 at 12:14 pm

    Re: For Apache 2.2 on RH 6.5 I get this error: SSLCertificateKeyFile: file ‘/etc/pki/tls/private/device.key’ does not exist or is empty.

    Reply
  24. Costas says:
    February 23, 2016 at 12:50 pm

    With cPanel I am also being asked for “Certificate Authority Bundle” in addition to the key and certificate. Is it possible to have self certified certificates on cPanel hosts?

    Reply
  25. Costas says:
    February 23, 2016 at 1:14 pm

    Not sure if my last post is still pending approval but I didn’t see any notice so I am posting again.
    I tried your system on a cPanel hsoted server and it is asking for the Certificate Authority Bundle for the certificate. Is it not possible to add self signed certificates to cPanel hosts?

    Reply
  26. Pankaj Chhabra says:
    March 7, 2016 at 10:46 am

    How to generate intermed certificate?

    Reply

  27. Pingback: SSL certificates - can they be used on more than one server * VPN SSL Online

  28. Pingback: Confluence: Production Engineering

  29. Oblivion Life says:
    May 25, 2016 at 5:26 pm

    Would you also know how to create an end entity certificate with OpenSSL?

    Reply
  30. ellayaraja says:
    September 29, 2016 at 12:09 am

    Once I have created Self Sign certificate in Trusted Root Certificates, How to we access this from c# to make web http request? If any one know helps me.

    Reply
  31. jolly says:
    October 7, 2016 at 10:46 am

    I need to try this hope it work for me i really want to have this SSL.

    Thanks for Sharing.

    Reply

  32. Pingback: Creating an SSL Certificate Authority (CA), signing certificates and authenticating using a client certificate | Squirrel5 – Linux Systems Administration services

  33. Renato Oliveira says:
    November 18, 2016 at 6:10 am

    Thak you! Great post!

    Reply
  34. anonymous says:
    November 19, 2016 at 11:51 pm

    Thank you very much. This helped me a lot

    Reply
  35. farhanahmad123 says:
    November 21, 2016 at 4:34 am

    Great article. Just a small thing, If I am generating certs for clients also, then client.crt and client.key will be at client side, and on server? will only rootca.pem in truststore will be enough? since client certs are signed with rootca or do i need to copy client.crt on server to make it work?

    Reply
  36. Online says:
    December 12, 2016 at 9:50 am

    How to generate intermediate certificate here with root?

    Reply
  37. errornosignal says:
    December 17, 2016 at 2:15 pm

    Excellent tutorial!

    Reply
  38. Billy says:
    January 13, 2017 at 12:39 pm

    OpenSSL is creating a .pem cert. Chrome will not recognize it.

    Reply
  39. tonsofsteel says:
    January 13, 2017 at 12:40 pm

    OpenSSL is creating a .pem cert. Chrome won’t recognize it…

    Reply
  40. Gaurav says:
    January 24, 2017 at 4:08 am

    Great explanation.
    One more thing i just wanted to know, if i update the CA certificate using different RSA key (2096) and keeping all information same and authorize my client certificate using that, now if i update the CA certificate to server and trying to authenticate the client it is failing. Error 20 no local issue CA certificate for the client. I require a server restart before authenticating using new CA and User certificate, why a server restart is require?

    Thanks,

    Reply
  41. lactus says:
    March 2, 2017 at 6:04 am

    Great article.
    But after installing rootCA.pem in firefox, i get SEC_ERROR_INADEQUATE_KEY_USAGE and no option to allow the certificate.
    Without installing the rootCA, i get only SEC_ERROR_UNKNOWN_ISSUER, this should be normal for selfsigned certs

    Are there any limitations in filling the forms other than the common name? May I use the same values?

    Reply
    • lactus says:
      March 2, 2017 at 8:41 am

      Problem was in openssl.cnf:
      keyUsage must include cRLSign and keyCertSign

      ie:
      keyUsage = cRLSign, keyCertSign

      Reply
  42. Andrej says:
    April 11, 2017 at 5:46 am

    Is it possible to create a v3 certificate with the last command?

    Reply
  43. Virendra Singh says:
    April 12, 2017 at 11:06 pm

    This looks good if you control the browser, in case where i have a site and people around the world buy stuff from my site. I dont control their browsers, why would they listen to my instructions to setup their browsers to install the certificate? Not sure if I am missing something.

    Reply
    • tonybourke says:
      April 12, 2017 at 11:46 pm

      You are correct. For users you don’t know, a typical certificate would be appropriate. This is for the situation where you control the gear and you control the browser, and wanting to use the trust aspect of SSL without paying a certificate authority.

      An example would be the user interface on an F5 load balancer or even your home Wifi router. You want to use encryption, but you get that “warning” every time you hit the site because while the communication is encrypted, it’s not “trusted”. This allows you to do trust (and at the very least, get rid of that annoying error message).

      Reply
  44. mmangosoft says:
    April 26, 2017 at 5:45 am

    Thank you very much! Great article. I have just generated a set of self-signed certificates.

    Reply
  45. David Zapata says:
    May 3, 2017 at 5:53 pm

    I have executed all steps as explained, although I have a doubt with the final result: Shouldn’t the final device.crt, when checking it’s details, show a certification path where the root id the CA certificate we created first? I did all steps and the final device.crt only shows itself in the certification path. Is this OK?

    Reply
  46. Jane Mary says:
    June 21, 2017 at 12:58 pm

    Hi, thanks for this nice step-by-step tutorial. I just did a thing like this in a company network, and I just want to add that when it comes to root certificate deployment, Firefox has an option to use the system’s certificate repository as well. (Windows 7 in my case.)
    In Firefox’s about:config, find a key named security.enterprise_roots.enabled and set it to True (False by default).
    That said, it should “just work” on most setups. Maybe you need to flush an individual system’s browser and/or dns cache first (as in “when was the last time you shut down your computer?” – “errrmmm, dunno… February?”), but all in all, it worked surprisingly well on a multitude of years-old Windows setups.

    Reply
  47. Andrew Landen says:
    June 23, 2017 at 3:59 pm

    New browser requirements involve san: Subeject Alternative Naming. Can you add where that process fits in your guide and how to meet those requirements?

    Reply
    • DRUMDUDESAN says:
      May 28, 2018 at 12:02 pm

      Hi,
      I am in the same boat as you. This worked like a charm for years until Chrome 58 if I recall. Did you make any progress. I am stuck. Firefox will do the same shortly as well.
      Jeff

      Reply

  48. Pingback: Confluence: 中国大学MOOC

  49. Yong Shiuh Rong says:
    June 4, 2018 at 10:18 pm

    I tried to run req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem it gave me error as follow:

    Can’t open C:\Program Files\Common Files\SSL/openssl.cnf for reading, No such file or directory
    8380:error:02001003:system library:fopen:No such process:crypto\bio\bss_file.c:74:fopen(‘C:\Program Files\Common Files\SSL/openssl.cnf’,’r’)
    8380:error:2006D080:BIO routines:BIO_new_file:no such file:crypto\bio\bss_file.c:81:
    unable to find ‘distinguished_name’ in config
    problems making Certificate Request
    8380:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or environment variable:crypto\conf\conf_lib.c:272:
    error in req

    Reply
  50. Chek says:
    June 12, 2018 at 6:58 am

    how do you generate intermediate certificate from the CA.

    Reply

  51. Pingback: Updating the SSL/TSL Security Certificates for WebSphere Liberty Under IBM CLM Tools – Strongback Consulting

  52. Usman Khan says:
    July 10, 2018 at 3:46 am

    If a company wish to be become a commercial CA than what will be the process?

    Reply
  53. Roy says:
    November 27, 2018 at 7:36 am

    Will this work for hosting public web sites or not? If I give the public hosting provider the cert I create for enabling HTTPS, will this work or is this only for intranets and private devices?

    Reply
  54. Carl says:
    November 29, 2018 at 2:32 pm

    If I want to authenticate server to clients and vice versa with my own CA and put the client certificate (public key), its private key in at PKCS#12 file and store it on the client application (mobile app), would the steps be:
    1. Create my own CA
    a) Create CA private key
    b) Use the private key to sign the CA certificate which is a public key

    2. Create the server certificate
    a) Create server private key
    b) Create certificate with the private key
    c) Sign it with the CA’s private key

    3. Create the client certificate
    a) Create client private key
    b) Create certificate with the private key
    c) Sign the client certificate with the CA’s private key

    Correct?
    Wouldn’t it be a dangerous, if the private key of the client is on the clientside application?

    Thanks

    Reply

  55. Pingback: Barbican Consumption and Operational Maintenance - OpenStack Blog for VMware - VMware Blogs

  56. Lyas Spiehler says:
    May 2, 2019 at 4:42 am

    https://certificatetools.com makes this very simple and generates the OpenSSL commands you can use to do it offline.

    Reply

  57. Pingback: MongoDB: Getting SSL peer certificate validation failed: self signed certificate - Boot Panic

  58. Andy Globe says:
    May 17, 2022 at 6:34 am

    This was super helpfull!! Thank you

    Reply

  59. Pingback: Failed to sign CSR with the CA root key

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.