Create Self-Signed S/MIME Certificates

What if you need to send an e-mail containing sensitive information? Do you send anything and everything through e-mail without concern for prying eyes? Recent news stories about e-mail account hacks and interceptions by third-parties make me even more hesitant and unwilling to send anything of importance through standard plain-text e-mail. If you’ve ever been through the process of buying a home, the amount of sensitive information that is transferred between the various parties is astounding and, from my experience, it is primarily done through plain-text e-mail (gasp). So, what can you do?

While this post doesn’t address the larger systemic issues around private information transfer, it does provide a basic method for public-key encryption and signing of MIME data (e-mail) using the S/MIME (Secure/Multipurpose Internet Mail Extensions) standard. Most well-known e-mail clients support S/MIME and this post provides instructions for creating your own certificate authority (CA) to create self-signed S/MIME certificates.

For those using an iOS or iPadOS device and Apple Mail, after completing the guide below and creating your self-signed certificate, please read Using Self-Signed S/MIME Certificates in iOS Mail App. It guides you through the steps to add your self-signed certificates to the Apple Mail app for S/MIME usage. For those using Microsoft Outlook, please read Using Self-Signed S/MIME Certificates in Outlook to guide you through the process of adding the personal certificate authority to the Windows trust store and using your self-signed certificate in Microsoft Outlook. For those using Mozilla Thunderbird, please read Using Self-Signed S/MIME Certificates in Thunderbird after completing this guide.

UPDATED (March 2023): I tested the steps on a Windows 10 64-bit machine using both the Win64 OpenSSL v3.1.0 Light distribution (EXE) and the Win64 OpenSSL v1.1.1t Light distribution (EXE) from Win32/Win64 OpenSSL Installer for Windows – Shining Light Productions.

A (Very) Brief Primer on Public-key Encryption

Prepare to be confused!

Since certificates are based on public-key encryption (also known as public-key cryptography or asymmetric cryptography), please keep in mind that you will need to have the public key of the intended e-mail recipient in order to encrypt the e-mail. Conversely, if someone wants to send you an encrypted e-mail, that person needs your public key. As an example, if I want to send an e-mail to Bob, I will need Bob’s public key to encrypt the e-mail. When Bob receives the encrypted e-mail, Bob’s e-mail client uses his personal private key to decrypt the e-mail. If Bob wants to send me an e-mail, he will need my public key to encrypt the e-mail. This post steps through the creation of your own personal public/private key pair. The public key is what an e-mail sender will need to encrypt an e-mail sent to you. Your private key is kept only by you since that is used to decrypt any e-mails encrypted using your public key. If your private key is obtained by anyone else, then that person would be able to decrypt and read your e-mails.

Public-key Cryptography Overview
Public-key Cryptography Overview

Is There an Easier Way?

Yes. You can obtain a basic certificate for free from a number of companies such as Comodo.

Where’s the fun in that? By creating your own certificate, you do not rely on an external party and you get to learn a little bit more along the way.

You’ve made it this far, so let’s get started.

Step 1 – Install OpenSSL

We will use OpenSSL to create a certificate authority which will then sign the certificate that we create. The latest OpenSSL toolkit is found at the OpenSSL site. If a binary distribution is needed, e.g., pre-compiled installation files for Microsoft Windows, those can be found on the OpenSSL binaries page.

Once you’ve found the appropriate distribution for your operating system, please proceed with the installation instructions provided with that distribution.

I am using a Windows distribution so portions of this post may be specific to that operating system. Please also note that I have installed OpenSSL in the c:\openssl\ directory.

Step 2 – Create an OpenSSL Configuration File

NOTE: This step may not be necessary depending on the OpenSSL distribution used. In some distributions of OpenSSL, the basic configuration file already includes the required extensions referenced below. In other distributions, a basic configuration file isn’t provided at all. If the default configuration file has the following extensions and you duplicate them in your own custom configuration file, then errors will be thrown in Step 4 and Step 7. With the distribution I used (referenced above), there is a default configuration file containing the appropriate [req], [req_distinguished_name], and [v3_ca] sections.

NOTE: With the distribution I used (referenced above), there is a default configuration file containing the appropriate [req], [req_distinguished_name], and [v3_ca] sections so I do not need those sections in my smime.cnf. However, I do use smime.cnf and, specifically, the [smime] section to set the appropriate extensions in Step 7. If you are using the same distribution, the default configuration file may be found at c:\Program Files\Common Files\SSL\openssl.cnf.

Now that OpenSSL is installed, a configuration file is needed. If openssl.exe is executed at this point without the configuration file in place, the message WARNING: can’t open config file: /usr/local/ssl/openssl.cnf may be received.

Create a new file named smime.cnf containing the following configuration. The contents of the file follow the x509 certificate extension configuration format. For more information about the format and content, please review x509 v3 configuration page. The [req] and [req_distinguished_name] sections are generally part of any standard OpenSSL configuration file. Some distributions include a default configuration file that includes some version of these sections. I included them specifically in this configuration file because I was receiving an error message stating unable to find ‘distinguished_name’ in config and this resolved the error.

NOTE: The [v3_ca] and [smime] sections are the important for this exercise because they set the appropriate extensions for an S/MIME certificate authority and personal certificates.

[req]
distinguished_name = req_distinguished_name

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Some-State
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Internet Widgits Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64

[v3_ca]
basicConstraints = critical, CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer

[smime]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = emailProtection
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer
subjectAltName = email:copy

Next, we will need to set the OPENSSL_CONF environment variable to reference the new configuration file. Setting this environment variable will eliminate the warning message mentioned earlier. This part is Windows specific. Recall that I have installed OpenSSL in the c:\openssl\ directory, named the configuration file smime.cnf, and saved it in the c:\openssl\ directory.

Open a command prompt window and be sure to Run as administrator if you are on Windows. Execute the following command:

set OPENSSL_CONF=c:\openssl\smime.cnf

When openssl.exe is executed (from the c:\openssl\bin\ directory), there is no warning message and the OpenSSL> prompt is displayed. Type exit and you’ll be returned to the c:\openssl\bin\> prompt.

For those using Windows, if you ever need to remove the OPENSSL_CONF environment variable, then use the following command to launch the Environment Variables dialog box to create, edit, or delete user or system variables.

rundll32 sysdm.cpl,EditEnvironmentVariables

Step 3 – Generate an RSA Private Key for the Certificate Authority

NOTE: The following steps and OpenSSL commands should be executed from the command prompt (on Windows) and not in OpenSSL interactive mode.

In this post, we are creating a new certificate authority to sign personal certificates. Execute the following command to generate the RSA private key for the new certificate authority:

openssl genrsa -aes256 -out ca.key 4096

The options specify to use the aes256 encryption cipher and output the results to a file named ca.key with a size of 4096 bits. Please be aware that the corresponding public key is derived from this private key. No extra step or command is required to generate the public key.

The following message will be displayed using OpenSSL 1.1x versions. Follow the prompts to create a pass phrase for this key. Remember this pass phrase for subsequent steps.

Generating RSA private key, 4096 bit long modulus (2 primes)
........................................................++++
...............................................++++
e is 65537 (0x010001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:

The message is modified slightly using OpenSSL 3.x versions, but the intent is the same.

Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

Step 4 – Create Self-Signed Certificate for the Certificate Authority

NOTE: As mentioned in Step 2, if the distribution already has a proper configuration file then the smime.cnf file created in Step 2 is unnecessary and the last argument should be excluded from the command, i.e., remove “-extensions v3_ca”.

Execute the following command to generate the new self-signed certificate for the certificate authority:

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -extensions v3_ca

The -x509 option outputs a self-signed certificate instead of a certificate request. The -days 3650 option specifies that the generated certificate is certified for 10 years (ignoring leap years). The -key option specifies the private key to use. We will use the private key (ca.key) that was created in Step 3 and output the self-signed certificate to a file named ca.crt.

Follow the displayed prompts. You will need to use the pass phrase from Step 3. I have left most fields blank by simply entering a . character. I have provided example entries below between the brackets following the prompts. Please change the values to meet your own particular needs. Do not include the brackets in your entries.

Enter pass phrase for ca.key:
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]:[.]
State or Province Name (full name) [Some-State]:[.]
Locality Name (eg, city) []:[.]
Organization Name (eg, company) [Internet Widgits Pty Ltd]:[TEST COMPANY]
Organizational Unit Name (eg, section) []:[.]
Common Name (e.g. server FQDN or YOUR name) []:[TEST COMPANY CERTIFICATE AUTHORITY]
Email Address []:[.]

The certificate authority has been created. Now, we will begin creating the personal certificate for a particular e-mail address.

Step 5 – Generate an RSA Private Key for the Personal E-Mail Certificate

Similar to Step 3, we will need to create a new private key. This private key is for your personal certificate instead of the certificate authority. Again, please be aware that the corresponding public key is derived from this private key. No extra step or command is required to generate the public key.

Execute the following command:

openssl genrsa -aes256 -out smime_test_user.key 4096

When prompted, enter a pass phrase that is different from the one used in the certificate authority private key. The following is the output using OpenSSL 1.1x versions.

Generating RSA private key, 4096 bit long modulus (2 primes)
........++++
.................++++
e is 65537 (0x010001)
Enter pass phrase for smime_test_user.key:
Verifying - Enter pass phrase for smime_test_user.key:

Again, the message is modified slightly using OpenSSL 3.x versions, but the intent is the same.

Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

Step 6 – Create the Certificate Signing Request

Now that we have a personal private key, we will need to create a certificate signing request. This command looks similar to Step 4 where we created a self-signed certificate for the certificate authority. In this step, however, the options are slightly different because we are creating a certificate signing request instead of a self-signed certificate. We are creating a certificate signing request because we will use the certificate authority to sign the certificate.

Execute the following command:

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

When prompted, enter the pass phrase used to create the private key in Step 5. Again, I have left most fields blank by simply entering a . character. I have provided example entries below between the brackets following the prompts. The example uses a fake person named Test User with an e-mail address of test_user@dalesandro.net. As always, please change the values to meet your own particular needs. Do not include the brackets in your entries.

Please note that the Common Name used in this step should be different from the one used in Step 4. I also didn’t set a challenge password or company name in the final two entries.

Enter pass phrase for smime_test_user.key:
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]:[.]
State or Province Name (full name) [Some-State]:[.]
Locality Name (eg, city) []:[.]
Organization Name (eg, company) [Internet Widgits Pty Ltd]:[TEST COMPANY]
Organizational Unit Name (eg, section) []:[.]
Common Name (e.g. server FQDN or YOUR name) []:[Test User]
Email Address []:[test_user@dalesandro.net]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Step 7 – Sign the Certificate Using the Certificate Authority

NOTE: As mentioned in Step 2, if the distribution already has a proper configuration file then the smime.cnf file created in Step 2 is unnecessary and the last two arguments should be excluded from the command, i.e., remove “-extfile c:\openssl\smime.cnf -extensions smime”. Please confirm that the extensions listed in the [smime] section in the above configuration file exist in the default configuration before removing the last two arguments.

At this point, we are finally creating the personal self-signed certificate. We will use the configuration file we created in Step 2 to set the necessary extensions and we will use the certificate authority to sign the new personal certificate.

Execute the following command (incrementing set_serial with each signing request):

openssl x509 -req -days 3650 -in smime_test_user.csr -CA ca.crt -CAkey ca.key -set_serial 1 -out smime_test_user.crt -addtrust emailProtection -addreject clientAuth -addreject serverAuth -trustout -extfile c:\openssl\smime.cnf -extensions smime

When prompted, enter the pass phrase for the certificate authority private key from Step 3.

Signature ok
subject=O = TEST COMPANY, CN = Test User, emailAddress = test_user@dalesandro.net
Getting CA Private Key
Enter pass phrase for ca.key:

NOTE: Repeat Steps 5 through 7 to create certificates for additional e-mail addresses. In Step 7, increment the set_serial argument (or assign a new unique number) for each additional certificate.

Step 8 – Package the Certificate into the PKCS12 Format

After all of that work, I imagine you’ll want to use your new self-signed digital certificate to send e-mail. Many e-mail clients will need the certificate packaged in a standard format. This step bundles the necessary files into the PKCS12 format.

Execute the following command:

openssl pkcs12 -export -in smime_test_user.crt -inkey smime_test_user.key -out smime_test_user.p12

When prompted, enter the pass phrase associated with your personal private key created in Step 5. You will also create another pass phrase which is used when importing the P12 file into an e-mail client.

Enter pass phrase for smime_test_user.key:
Enter Export Password:
Verifying - Enter Export Password:

Summary

You now have your very own self-signed S/MIME certificate which can be used to send signed e-mails. This also allows others to send you encrypted e-mails by using your public key. Once your recipients provide you with their public keys, then you’ll be able to send encrypted e-mails to them as well.

Further Reading

Common Issues

Missing Key Usages and Extensions

Based on the comments that this post receives, the most common issue is associated with Step 7 where the required key usages are not included in the certificate due to an improper configuration file. If these extensions are not included in the certificate, then the mail client will not use the certificate for digital signatures or encryption. To verify that the certificate includes the required extensions, execute the following command.

openssl x509 -in smime_test_user.crt -purpose -noout -text

This command outputs a list of certificate purposes and extensions as well as the public key itself. Verify that the certificate includes the following (highlighted in red):

  • S/MIME signing = Yes
  • S/MIME encryption = Yes
  • X509v3 Key Usage = Digital Signature, Non Repudiation, Key Encipherment
  • X509v3 Extended Key Usage = E-mail Protection
  • Trusted Uses = E-mail Protection
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : No
SSL server CA : No
Netscape SSL server : No
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : No
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No
Time Stamp signing : No
Time Stamp signing CA : No
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O = TEST COMPANY, CN = TEST COMPANY CERTIFICATE AUTHORITY
        Validity
            Not Before: May 17 19:20:33 2022 GMT
            Not After : May 14 19:20:33 2032 GMT
        Subject: O = TEST COMPANY, CN = Test User, emailAddress = test_user@dalesandro.net
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage:
                E-mail Protection
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:
                keyid:

            X509v3 Subject Alternative Name:
                email:test_user@dalesandro.net
    Signature Algorithm: sha256WithRSAEncryption
Trusted Uses:
  E-mail Protection
Rejected Uses:
  TLS Web Client Authentication, TLS Web Server Authentication

Certificate Authority Trust

Since we are creating self-signed certificates instead of using a well-known certificate authority, no operating system or mail client will recognize nor trust your certificate authority by default. Your certificate authority will need to be added to the operating system or mail client trust store before any personal certificates signed by that certificate authority are recognized and trusted as valid. By paying well-known providers for a certificate, you avoid this administrative hassle. This is the price you pay to do it yourself.

44 thoughts on “Create Self-Signed S/MIME Certificates”

  1. John, Thanks for the tips. It took me a few goes to understand how to adjust. At first when I tried to go iPhone to iPhone I could not decrypt the sent email (unless the message was signed too). I found the fix to get iOS to play along was in step 6 to only put in the email address, just leave everything else blank. I also adjusted the smime.cnf file to take out nonRepudiation, but that may have had nothing to do with getting it working.

    Many thanks for the great web page

    Reply
  2. John, thanks for this awesome guide, it saved me a lot of time! Easy to follow and reduced to the essential things.
    Since Comodo doesn’t offer free smime certificates anymore (you can still get one but they are only valid for 30 days), this is exactly what I need to create certificates for testing purposes.

    Reply
  3. when executing step 7 i keep getting this error, the pass phrase for the CA is defintely correct, have tried multiple times. any ideas?

    Getting CA Private Key
    Enter pass phrase for ca.key:
    unable to load CA Private Key
    1348:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto\evp\evp_enc.c:583:
    1348:error:0906A065:PEM routines:PEM_do_header:bad decrypt:crypto\pem\pem_lib.c:461:

    Reply
  4. For some reason, I’m stuck at Step 7 and get the following error.

    26596:error:2207707B:X509 V3 routines:V2I_AUTHORITY_KEYID:unable to get issuer keyid:./crypto/x509v3/v3_akey.c:166:
    26596:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:./crypto/x509v3/v3_conf.c:93:name=authorityKeyIdentifier, value=keyid:always,issuer

    Anyone got any idea?

    Reply
    • Depending on which distribution of OpenSSL is used, Step 7 may need to be adjusted to remove “-extfile smime.cnf -extensions smime”. I think the newer builds of OpenSSL have basic configuration files that include the necessary extensions making Step 2 (wholly or partially) unnecessary.

      Reply
  5. Hi,
    I am using your instruction and create CARoot cert and signing for each different email s/mime certs. On Windows I don’t have problem but on iOS and Mac I can’t import them. I can import one cert but not the other. So is it possible to use same CARoot to sign multiple s/mime account for iOS and MacOS?

    Reply
    • The Certificate Authority created in steps 3 and 4 is used to sign all of the e-mail certificates created in steps 5 through 8. In other words, steps 3 and 4 are performed only once, but steps 5 through 8 are repeated for each e-mail address requiring a certificate.

      I can’t comment on your specific issue with iOS/MacOS.

      Reply
  6. I am able to successfully send/receive digitally signed emails. However the encryption portion is throwing me for a loop. The recipient’s email client(s) do not trust my certificate authority. As such, they cannot send me encrypted emails.

    They have tried telling the client to “always trust” my Self Signed Certificate. Any suggestions?
    I have screen shots that I can share.

    Reply
    • You may try the following: The recipient installs the public part of your CA (the one you signed your email certificate with) as a trusted authority on their PC (or server or whatever).
      When your Root Certificate Authority is known at the recipients infrastructure, it should accept your email certificate as it knows the CA then.

      Reply
      • That is the correct answer. Since you are creating your own Certificate Authority and it obviously isn’t one of the well-known industry providers, e.g. VeriSign or Thawte, etc., it isn’t automatically recognized/trusted by any application. Both the sender and receiver of any e-mails signed/encrypted by your Certificate Authority should install the public key of your Certificate Authority as a Trusted Authority. Some applications may continue to flag your CA since it isn’t well-known, but the expected functionality will still work.

        Reply
  7. Hi Sir. I followed the instructions above and got my .P12 but my iOS 14.3 device does not seem to detect the certificate for signing/encryption after importing it. Any idea why ?

    Reply
    • I don’t know about iOS, but when I followed the above directions for Thunderbird on an up-to-date Fedora (Linux) system, I had a similar experience.

      I first tried creating the smime.cnf file, as above, set the OPENSSL_CONF environment variable, and also used the “-extfile smime.cnf -extensions smime” switches on the “openssl x509” command. This gave a similar error to the one seen by Dung Tran, but starting with:
      140660223952704:error:06067099:digital envelope routines:EVP_PKEY_copy_parameters:different parameters:crypto/evp/p_lib.c:93

      I removed the two switches, and then the “openssl x509” command completed without errors; but when the resulting .p12 file was imported to Thunderbird, there were no “Key Usages” included in the certificate, so nothing indicating that it should be used for signing or encryption.

      I then trimmed the smime.cnf file to ONLY the “[smime]” section, unset (deleted) the OPENSSL_CONF environment variable so that the distribution openssl.cnf file would be used (which has no [smime] section), and restored the two switches on the “openssl x509 ….. -extfile smime.cnf -extensions smime” command so that the smime.cnf file would be used only to obtain the smime options. After repackaging the .p12 file, this produced a working certificate with the correct “Key Usages” listed. Note that for Thunderbird, in Certificate Management, the ca.crt file (from above) must be imported under the Authorities tab, AND the users .p12 file must be imported under the “Your Certificates” tab; probably something similar for other Email clients. The ca.crt file must also be given to any other person you want to exchange encrypted Email with, as was discussed in the comments above.

      I can’t say whether this will help you, but you might try the combination given in the last paragraph, above.

      Reply
  8. Please help. I followed the steps flawlessly and within outlook i have managed to import the cert in trust centre-email security settings. However on trying to use it I get an error message stating “Microsoft Outlook cannot sign or encrypt this message because there are no certificates which can be used from the email address “************”. Either get a new digital ID to use with this account, or use the accounts button to send the message using an account that you have certificates for” at every stage i put in my correct email address so i am unsure what i am missing.

    Reply
    • I’ve tested the process and resulting certificate with Office 2019 and it worked fine. While I didn’t get the specific error you referenced, Outlook did throw an “Invalid Certificate” error and it wouldn’t allow me to send signed/encrypted e-mails. The error message was “Microsoft Outlook cannot sign or encrypt this message because your certificate is not valid.” I added the Certificate Authority certificate “ca.crt” to the “Trusted Root Certification Authorities”. Once that was in place, Outlook presented a few more click-through warnings, but I was finally able to sign and encrypt e-mails (and decrypt).

      Reply
      • The solution John gave resolved my issue. I realized the prompt that gave the long message Daniel first posted had a title in small letters that said “invalid certificate”. I added the Certificate Authority certificate “ca.crt” to the “Trusted Root Certification Authorities” as John suggested and, BOOM, it worked!

        Reply
  9. Sorry, I still don’t know how to send a public key to another individual so that they can read my encrypted email. How do you send your public key to another individual?

    Reply
    • When you send a signed e-mail, the recipient receives your public key. The recipient would then install/register your public key in their e-mail client to be able to send you an encrypted e-mail.

      Reply
  10. Although I can successfully create a certificate, I can’t get any clients to accept them. They can be imported, but for some reason cannot be used, and the client tells me either the certificate file doesn’t exist or is expired. I am using Thunderbird mainly, and I have imported my certificate as an authority. Is it possible I’m missing some requirement in my config file? I followed your instructions to the letter aside from file names and form details.
    I do want to use this method though, so I’m not bound to a company. I don’t care if no platforms support it.

    Reply
  11. Hi there,

    I followed exactly these steps somehow am stuck at step 6.

    # I ran this command
    OpenSSL> req -new -key smime_test_user.key -out smime_test_user.csr

    #Promted
    problem creating object tsa_policy1=1.2.3.4.1
    2308:error:08064066:object identifier routines:OBJ_create:oid exists:crypto\objects\obj_dat.c:698:
    error in req

    Looking forward to your help.

    Reply
    • Run each of these steps from the command line and not in OpenSSL interactive mode. As an example, for Step 6, run it as: c:\openssl\bin\>openssl req -new -key smime_test_user.key -out smime_test_user.csr

      Reply
    • By sending a signed e-mail, the recipient’s e-mail client is able to extract your public key directly from the digital signature. There’s no need to manually extract and send your public key separately unless the recipient is using an outdated or incomplete client. Consult the OpenSSL documentation for specific commands in that instance.

      Reply
  12. Be aware that if you set OPENSSL CONF variable, before you generate CA cert (step #4 ), then it will not contain Authority Key Identifier, and step #7 will fail.
    To solve this, append the following section to smime.cnf file:

    [ v3_ca ]
    basicConstraints = critical,CA:TRUE
    subjectKeyIdentifier = hash
    authorityKeyIdentifier = keyid:always,issuer:always

    and in step #4 use openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -extensions v3_ca command insted.

    Reply
    • Good catch. The most recent OpenSSL builds for Windows include a proper configuration file which generally eliminates the need for smime.cnf in these steps. For those who still need smime.cnf, I have updated the example configuration file and the relevant command step.

      Reply
  13. When I receive an email for the first time with a self-signed certificate, is there an option to just trust that individual certificate, or must I trust all emails created by that self signed ca? Outlook seems to want me to trust the ca and I would rather just trust the one user certificate.

    Reply
  14. I tried to use this key to export this certificate to use in my php script (phpmailer) :

    openssl pkcs12 -in smime_test_user.p12 -nocerts -out cert.key

    openssl pkcs12 -in smime_test_user.p12 -clcerts -nokeys -out cert.crt

    openssl pkcs12 -in smime_test_user.p12 -cacerts -out certchain.pem

    The exported certificate doesn’t work. It gives “signing error”.

    So I got a S/MIME certificate in PKCS12 from a external certificate authority. I then made a cert.crt, cert.key & certchain.pem as stated above and now it works.

    I don’t understand why I can use my self signed certificate.

    Reply
    • Compare your self-signed certificate with the one issued by the external certificate authority. Does your self-signed certificate include the same certificate purposes, trusted uses, key usages, and extensions?

      Reply
  15. Hi John,
    I tried your steps and successfully imported in Thunderbird (I did all steps in Ubuntu). But now when I tried to send a test email to another email account and wanted to digitally sign the email , I got a prompt saying:
    You specified that this message should be digitally signed, but the application either failed to find the signing certificate specified in your Mail & Newsgroup Account Settings, or the certificate has expired.”
    I could not figure out what it meant. I checked the expiry or validity of the certificate, that seems alright.

    Reply
    • I haven’t seen that error, but I would guess that it may be related to the self-created certificate authority used to sign your personal certificate. If you haven’t established trust for your certificate authority in Thunderbird or the underlying O/S, then Thunderbird won’t trust any certificates, including your personal certificate, issued by that certificate authority.

      I suggest following these instructions if you haven’t done so already (specifically Step 4 – Establish Certificate Authority Trust). While these instructions cover Thunderbird on Windows, it may also be applicable to Ubuntu.

      Reply
  16. Dear John,
    thanks a lot for this amazing tutorial!!
    I´ve just made Certificates for all my Family :-)

    However I struggled with Unicode/UTF-8 Coding under the Windows Version of OpenSSL.
    Had errors like this all the time, no matter what I tried:

    Error making certificate request
    ########:error:06800086:asn1 encoding routines:ASN1_mbstring_ncopy:invalid utf8string:crypto\asn1\a_mbstr.c:85:

    I ended with Ubuntu 22.04 LTS via the Windows Linux-Subsystem and then was everything ok!
    Command were absolutely same, so no problem at all. Windows Partitions are automatically mounted, so it was easy to copy all the certificates to the Windows Enviroment after all.

    Best regards
    Lore

    Reply
    • Thank you for the feedback! With respect to the error, it would be helpful to know which specific command threw the error and an example of the entered data. I tried generating a new request with Unicode characters on Windows and I didn’t encounter the error.

      Reply
  17. Hi, John! Is it possible to use ECC cryptography in the personal email certificates (not the CA) instead of RSA? Have you ever tried that? Thanks for your awesome guide that helped me a lot!

    Reply
    • The good news is that only Step 5 needs to be adjusted to use ECC instead. All other steps remain the same.

      To get a list of all curve short names, execute the following command:

      openssl ecparam -list_curves

      The output will look similar to the following list (shortened for this comment):

        secp112r1 : SECG/WTLS curve over a 112 bit prime field
        secp112r2 : SECG curve over a 112 bit prime field
        secp128r1 : SECG curve over a 128 bit prime field
        secp128r2 : SECG curve over a 128 bit prime field
        secp160k1 : SECG curve over a 160 bit prime field
        secp160r1 : SECG curve over a 160 bit prime field
        secp160r2 : SECG/WTLS curve over a 160 bit prime field
        secp192k1 : SECG curve over a 192 bit prime field
        secp224k1 : SECG curve over a 224 bit prime field
        secp224r1 : NIST/SECG curve over a 224 bit prime field
        secp256k1 : SECG curve over a 256 bit prime field
        secp384r1 : NIST/SECG curve over a 384 bit prime field
        secp521r1 : NIST/SECG curve over a 521 bit prime field
      

      Select an appropriate curve short name from the list and modify/execute the following command.

      openssl ecparam -name secp384r1 -genkey -noout -out smime_test_user.key

      You can continue with the remainder of the steps without modification. I haven’t tested if an ECC-based certificate works with the usual email clients, however, I imagine it should work as expected.

      Reply

Leave a Comment