Error Loading extension section usr_cert - ssl

I am running openvpn on an Ubuntu 14.04 box. The setup was fine until an OpenSSL upgrade, then when I try to create new client cert with easy-rsa, I got this message:
root#:easy-rsa# ./pkitool onokun
Using Common Name: onokun
Generating a 2048 bit RSA private key
.+++
........+++
writing new private key to 'onokun.key'
-----
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
Error Loading extension section usr_cert
3074119356:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:335:group=CA_default name=email_in_dn
3074119356:error:2207507C:X509 V3 routines:v2i_GENERAL_NAME_ex:missing value:v3_alt.c:537:
3074119356:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:v3_conf.c:93:name=subjectAltName, value=onokun
This problem is different from a reported bug that the which opensslcnf script can not find an matching version of openssl.cnf to use (above message shows openssl-1.0.0.cnf). I performed a Google search but did not find an answer.
Here are some environment information:
## openvpn
OpenVPN 2.3.2 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Feb 4 2014
Originally developed by James Yonan
## openssl
OpenSSL 1.0.1f 6 Jan 2014
## dpkg --get-selections | grep ssl
libgnutls-openssl27:i386 install
libio-socket-ssl-perl install
libnet-smtp-ssl-perl install
libnet-ssleay-perl install
libssl-dev:i386 install
libssl-doc install
libssl0.9.8:i386 install
libssl1.0.0:i386 install
openssl install
ssl-cert install
What should I look at to solve this? Thanks,

Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
Error Loading extension section usr_cert
I don't have a /etc/openvpn/easy-rsa/openssl-1.0.0.cnf, so take this with a grain of salt...
opensslconf.h from OpenSSL's distribution does include that section:
openssl-1.0.1h$ grep -R usr_cert *
apps/openssl-vms.cnf:x509_extensions = usr_cert # The extensions to add to the cert
apps/openssl-vms.cnf:[ usr_cert ]
apps/openssl.cnf:x509_extensions = usr_cert # The extensions to add to the cert
apps/openssl.cnf:[ usr_cert ]
Can you restore an old version of /etc/openvpn/easy-rsa/openssl-1.0.0.cnf?
Here's the section from apps/openssl.cnf. You might consider adding it to Easy RSA's configuration file if its missing. First, try an empty section. Then try adding the original code back.
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping

By comparing an earlier Ubuntu 14.04 install that did not have this problem, it seems the specific issue is with "subjectAltName". I didn't read up on what this does, but the command below will fix your "openssl-1.0.0.cnf" file:
perl -p -i -e 's|^(subjectAltName=)|#$1|;' /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
I should probably file a bug report.

I finally got his working (on my machine) Firstly my setup is a little different, I'm on Windows10, running OpenSSL 1.0.2h. I'm trying to generate multiple certificates, CAs and other things for tests, I am getting the error:
configuration file routines:NCONF_get_string:no value:.\crypto\conf\conf_lib.c:324:group=CA_default name=email_in_dn
To fix it I found placing the entry email_in_dn = no in CA_Default openssl.cfg section as bellow
####################################################################
[ CA_default ]
dir = ./demoCA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/ca.crt # The CA certificate
serial = $dir/serial # The current serial number
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/caprivkey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
email_in_dn = no # <-- fixes CONF_get_string:no value
I hope this helps someone else.

This is filed as a bug in Ubuntu. See SSL certificate creation crashes without subjectAltName.
The work-around described by Yuriy seems to work (copied from launchpad):
in the file /usr/share/easy-rsa/pkitool
just replace expressions:
KEY_ALTNAMES="$KEY_CN"
to:
KEY_ALTNAMES="DNS:${KEY_CN}"
In my version of the file this is line 284, just after the string "Using Common Name"

To get rid of this error:
3074119356:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:335:group=CA_default name=email_in_dn
use
-noemailDN
in the openssl command.
For example:
$ openssl ca -batch -config openssl.cnf -extensions usr_cert -noemailDN -days 375 -notext -md sha256 -in csr/www.example8.com.csr.pem -out certs/www.example8.com.cert.pem -verbose -passin pass:changeit

Related

cert in /etc/ssl/cert.pem expired today (MacOS Mojave)

The cert that is stored in /etc/ssl/cert.pem expired today on my Mojave computer, which has caused problems with my curl commands. Is there anyway to update it? I see that my Catalina computer has a newer certificate. Can I just copy it over to my Mojave computer?
Yesterday, the Let's Encrypt DST Root CA X3 root certificate expired, which is causing similar problems as you experienced: curl displays a SSL certificate problem: certificate has expired error when trying to access websites using the new Let's Encrypt ISRG Root X1 certificate.
On macOS Mojave (and maybe others, but this is what I use), the default curl uses certificates in /etc/ssl/cert.pem when verifying TLS connections (you can confirm this by by running curl -v https://example.com 2>&1 | grep CAfile).
The simplest fix is to delete the expired root certificate from the /etc/ssl/cert.pem file, assuming its replacement already exists in the file. This is enough to fix the expired DST Root CA X3, because its replacement, ISRG Root X1 already exists in the /etc/ssl/cert.pem file. Delete all lines from ### Digital Signature Trust Co. to -----END CERTIFICATE-----.
If you need to completely replace /etc/ssl/cert.pem with updated certificates, you can replace it with certificates exported from the macOS System Roots keychain:
Make a backup of the old /etc/ssl/cert.pem:
sudo cp /etc/ssl/cert.pem{,-orig}
Export system keychain and replace contents of /etc/ssl/cert.pem:
security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain | sudo tee /etc/ssl/cert.pem >/dev/null
Alternatively, you can tell curl to use a different certificate file like this:
curl -I --cacert /path/to/certificates.pem https://example.com/
Or configure the location of this file using the CURL_CA_BUNDLE=/path/to/certificates.pem environment variable.
For Mojave in 2022/02, here is a simple solution:
Backup the current version of /etc/ssl/cert.pem in your macOS.
Download the new CA certificate( officially recommended by curl.se), renaming it to cert.pem.
Replace the original one with the new one: sudo mv cert.pem /etc/ssl/cert.pem.
I think you have problem with AddTrust CA
What You Need to Do
For most use cases, including certificates serving modern client or server systems, no action is required, whether or not you have issued certificates cross-chained to the AddTrust root.
As of April 30, 2020: For business processes that depend on very old systems, Sectigo has made available (by default in the certificate bundles) a new legacy root for cross-signing, the “AAA Certificate Services” root. However, please use extreme caution about any process that depends on very old legacy systems. Systems that have not received the updates necessary to support newer roots such as Sectigo’s COMODO root will inevitably be missing other essential security updates and should be considered insecure. If you would still like to cross-sign to the AAA Certificate Services root, please contact Sectigo directly.
https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020
I tried Quinn Comendant's solution, but it didn't work.
I ended up solving this by installing OpenSSL and linking the cert.pem file to the one under OpenSSL (in MacOS Mojave):
$ sudo cp /etc/ssl/cert.pem /etc/ssl/cert.pem.bak
$ brew install openssl
$ brew info openssl
openssl#3: stable 3.0.0 (bottled) [keg-only]
Cryptography and SSL/TLS Toolkit
https://openssl.org/
/usr/local/Cellar/openssl#3/3.0.0 (6,415 files, 28MB)
Poured from bottle on 2021-10-04 at 11:13:17
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/openssl#3.rb
License: Apache-2.0
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
/usr/local/etc/openssl#3/certs
...
From this we'll know the config is in /usr/local/etc/openssl#3, then:
$ sudo rm /etc/ssl/cert.pem
$ sudo ln -s /usr/local/etc/openssl#3/cert.pem /etc/ssl/cert.pem
This solved my problem.
Thus far, the only working solution I can find is to just upgrade to Catalina. None of the above suggestions work because even Homebrew is broken because most of their mirrors use Let's Encrypt certificates. Adding a new ISRG Root X1 certificate file from http://x1.i.lencr.org/ to the system keychain and exporting to a new /etc/ssl/cert.pem doesn't even fix the problem.

Epson TM-T88V-i SSL Certificate issue

I have an Epson TM-T88V-i receipt printer which I print to using Epson's E-pos Javascript library. I have been using the following URL to print to the printer which is connected to my local network
http://192.168.1.105/cgi-bin/epos/service.cgi?devid=local_printer&timeout=60000
This has run fine while my application has been unsecured but I have now installed a certificate on my main domain to secure it from a trusted CA and have been facing the issue that when I print to the secure URL for the printer https://192.168.1.105/cgi-bin/epos/service.cgi?devid=local_printer&timeout=60000 it breaks the security of my main domain - flagging the site is not secure and crossing the HTTPS in red because it is loading content with certificate errors .
When I inspect the self-signed certificate generated by the printer it has the following issues:
Certificate - Subject Alternative Name missing The certificate for
this site does not contain a Subject Alternative Name extension
containing a domain name or IP address.
Certificate - missing This site is missing a valid, trusted
certificate (net::ERR_CERT_AUTHORITY_INVALID).
I have tried to add the certificate to my trusted certificate Authorities but this hasn't worked.
I have followed Epson's own guide to create a certificate using OpenSSL but I get the same error in my browser.
I have googled the above errors but just can't find a solution that works. Ignoring all Certificate errors is not an option as this is for a live production environment. I have enabled Allow invalid certificates for resources loaded from localhost and this too has not worked.
If I need to purchase certificate I will but don't know if A CA can issue one without a signing request
Any help will be greatly appreciated
This was the config that I got to work eventually from following this guide. Thanks to Mark Farrugia for pointing out to change the altNames from DNS.0 to IP.0 - This was what seemed to be the major sticking point for us
https://gist.github.com/jchandra74/36d5f8d0e11960dd8f80260801109ab0
#
# epson.cnf
#
[ req ]
prompt = no
distinguished_name = server_distinguished_name
req_extensions = v3_req
[ server_distinguished_name ]
commonName = 192.168.1.105
stateOrProvinceName = mystate
countryName = mycountry
emailAddress = myemail.email.com
organizationName = epson
organizationalUnitName = presales
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = #alt_names
[ alt_names ]
IP.0 = 192.168.1.105 -- this is the IP of the printer
It must be noted. I had to download the certificate and add it to Chrome's own trusted CA store on my other PC's. Once added It works as expected
Managed to sort the issue. Followed your tutorial but then make sure that when you come to the config of the actual certificate add IP.0 to the actual ip of the printer. Now my issue is that it does not connect to the printer using HTTPS through Javascript but a hack in the actual javascript should do it.
WHY: this is happen because of epson printer is not generated a valid certificated or untrusted by your PC, so it will block any connection to printer and have this warning like this image
HOW: go to your epson IP, then click process then PC will have printer certificate, then it can connect properly.
Go to this link and make some test:
https://xanhtool.github.io/epbex/
change this ip with your ip:
click send and get error:
open Advance and process:
send successful:

How to enable SSL on Apache Airflow?

I am using Airflow 1.7.0 with a LocalExecutor and documentation suggests that to enable SSL, we need to pass cert and key path and change the port to 443 as below
[webserver]
web_server_ssl_cert = <path to cert>
web_server_ssl_key = <path to key>
# Optionally, set the server to listen on the standard SSL port.
web_server_port = 443
base_url = http://<hostname or IP>:443
I have created cert and key generated using OpenSSL. The details supplied while creating the cert/key too are right.
However, the Airflow UI is still http and not https.
Any pointers would help!
Thank you!
Solved in this question How to enable SSL on Airflow Webserver? and answer https://stackoverflow.com/a/56760375/512111.
In short: generate a key, crt pair with
openssl req \
-newkey rsa:2048 -nodes -keyout domain.key \
-x509 -days 365 -out airflow.crt
and set in airflow.cfg like
web_server_ssl_cert = /path/to/airflow.crt
web_server_ssl_key = /path/to/airflow.key
Leave the webserver port unchanged. Restart the airflow webserver, go to https://hostname:port et voilà.
Airflow 1.7.0 doesn't support SSL. I just checked the webserver code of airflow 1.7.0. The code is given below. This function just starts the flask/gunicorn application on HTTP with the host and port. If you provide the certificate and mention the port as 443, it will simply start the application on http://<host>:443. It doesn't accept the SSL key and certificate. The webserver function of Airflow 1.7.0 is given below.
SSL feature is available with the latest version of the Apache Airflow. Please use the latest version for SSL support.
def webserver(args):
print(settings.HEADER)
from airflow.www.app import cached_app
app = cached_app(configuration)
workers = args.workers or configuration.get('webserver', 'workers')
if args.debug:
print(
"Starting the web server on port {0} and host {1}.".format(
args.port, args.hostname))
app.run(debug=True, port=args.port, host=args.hostname)
else:
print(
'Running the Gunicorn server with {workers} {args.workerclass}'
'workers on host {args.hostname} and port '
'{args.port}...'.format(**locals()))
sp = subprocess.Popen([
'gunicorn', '-w', str(args.workers), '-k', str(args.workerclass),
'-t', '120', '-b', args.hostname + ':' + str(args.port),
'airflow.www.app:cached_app()'])
sp.wait()
Go to AIRFLOW_HOME -> airflow.cfg. It has section named [webserver], under that there are two config properties like below:
web_server_ssl_cert =
web_server_ssl_key =
if there is no value like above means Airflow webserver is running on http (without certificate).
To enable SSL, use .p12 certificate (one you must have ordered) and use openssl to extract certificate and private key from .p12 file. openssl mostly ships with Linux so you can directly run on linux terminal.
Step1: Extract certificate using below command
openssl pkcs12 –in /path/cert.p12 -nokeys -clcerts –out /path/mycert.crt
Step2: Extract key using below command
openssl pkcs12 –in /path/cert.p12 -nocerts –out /path/mykey.key
Step3: Once certificate and key is generated, update airflow.cfg for
web_server_ssl_cert and web_server_ssl_key. Restart Airflow webserver.. are you
are done. Browse Airflow UI with https.

Creating self signed certificate for domain and subdomains - NET::ERR_CERT_COMMON_NAME_INVALID

I followed this tutorial for creating Signed SSL certificates on Windows for development purposes, and it worked great for one of my domains(I'm using hosts file to simulate dns). Then I figured that I have a lot of subdomains, and that would be a pain in the ass to create a certificate for each of them. So I tried creating a certificate using wildcard in Common field as suggested in some of the answers at serverfault. Like this:
Common Name: *.myserver.net/CN=myserver.net
However, after importing this certificate into Trusted Root Certification Authority, I'm getting NET::ERR_CERT_COMMON_NAME_INVALID error in Chrome, for main domain and all of its subodmains, for example: https://sub1.myserver.net and https://myserver.net.
This server could not prove that it is myserver.net; its security certificate
is from *.myserver.net/CN=myserver.net.
This may be caused by a misconfiguration or an attacker intercepting your connection.
Is there something wrong in Common Name field that is causing this error?
Chrome 58 has dropped support for certificates without Subject Alternative Names.
Moving forward, this might be another reason for you encountering this error.
A workaround is to add the domain names you use as "subjectAltName" (X509v3 Subject Alternative Name). This can be done by changing your OpenSSL configuration (/etc/ssl/openssl.cnf on Linux) and modify the v3_req section to look like this:
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net
With this in place, not forget to use the -extensions v3_req switch when generating your new certificate. (see also How can I generate a self-signed certificate with SubjectAltName using OpenSSL?)
As Rahul stated, it is a common Chrome and an OSX bug. I was having similar issues in the past. In fact I finally got tired of making the 2 [yes I know it is not many] additional clicks when testing a local site for work.As for a possible workaround to this issue [using Windows], I would using one of the many self signing certificate utilities available.Recommended Steps:
Create a Self Signed Cert
Import Certificate into Windows Certificate Manager
Import Certificate in Chrome Certificate ManagerNOTE: Step 3 will resolve the issue experienced once Google addresses the bug...considering the time in has been stale there is no ETA in the foreseeable future.**As much as I prefer to use Chrome for development, I have found myself in Firefox Developer Edition lately. which does not have this issue.Hope this helps :)
Create openssl.conf file:
[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = Cary
L = Cary
O = BigCompany
CN = *.myserver.net
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = #alt_names
[alt_names]
DNS.1 = myserver.net
DNS.2 = *.myserver.net
Run this comand:
openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt -config openssl.conf
Output files app.crt and app.key work for me.
Your wildcard *.example.com does not cover the root domain example.com but will cover any variant on a sub-domain such as www.example.com or test.example.com
The preferred method is to establish Subject Alternative Names like in Fabian's Answer but keep in mind that Chrome currently requires the Common Name to be listed additionally as one of the Subject Alternative Names (as it is correctly demonstrated in his answer). I recently discovered this problem because I had the Common Name example.com with SANs www.example.com and test.example.com, but got the NET::ERR_CERT_COMMON_NAME_INVALID warning from Chrome. I had to generate a new Certificate Signing Request with example.com as both the Common Name and one of the SANs. Then Chrome fully trusted the certificate. And don't forget to import the root certificate into Chrome as a trusted authority for identifying websites.
I think it may be a bug in chrome. There was a similar issue long back:
See this.
Try in a different browser. I think it should work fine.
If you're tired of this error. You can make Chrome not act out like this. I'm not saying it's the best way just saying it's a way.
As a workaround, a Windows registry key can be created to allow Google Chrome to use the commonName of a server certificate to match a hostname if the certificate is missing a subjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificates.
Data type: Boolean [Windows:REG_DWORD]
Windows registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
Windows/Mac/Linux/Android preference name: EnableCommonNameFallbackForLocalAnchors
Value: 0x00000001 (Windows), true(Linux), true (Android), (Mac)
To create a Windows registry key, simply follow these steps:
Open Notepad
Copy and paste the following content into notepad
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EnableCommonNameFallbackForLocalAnchors"=dword:00000001
Go to File > Save as
Filename: any_filename.reg
Save as type: All Files
Select a preferred location for the file
Click on Save
Double click on the saved file to run
Click on Yes on the Registry Editor warning
Found this information on Symantec support page:
https://support.symantec.com/en_US/article.TECH240507.html
For everyone who is encountering this and wants to accept the risk to test it, there is a solution: go to Incognito mode in Chrome and you'll be able to open "Advanced" and click "Proceed to some.url".
This can be helpful if you need to check some website which you are maintaining yourself and just testing as a developer (and when you don't yet have proper development certificate configured).
Of course this is NOT FOR PEOPLE using a website in production where this error indicates that there is a problem with website security.
The answers provided did not work for me (Chrome or Firefox) while creating PWA for local development and testing. DO NOT USE FOR PRODUCTION! I was able to use the following:
Online certificate tools site with the following options:
Common Names: Add both the "localhost" and IP of your system e.g. 192.168.1.12
Subject Alternative Names: Add "DNS" = "localhost" and "IP" = <your ip here, e.g. 192.168.1.12>
"CRS" drop down options set to "Self Sign"
all other options were defaults
Download all links
Import .p7b cert into Windows by double clicking and select "install"/ OSX?/Linux?
Added certs to node app... using Google's PWA example
add const https = require('https');
const fs = require('fs'); to the top of the server.js file
comment out return app.listen(PORT, () => { ... }); at the bottom of server.js file
add below https.createServer({
key: fs.readFileSync('./cert.key','utf8'),
cert: fs.readFileSync('./cert.crt','utf8'),
requestCert: false,
rejectUnauthorized: false
}, app).listen(PORT)
I have no more errors in Chrome or Firefox

How to install: OpenSSL + WAMP

Does anyone here have clear and detailed steps on how to get SSL on my local development machine? I've installed the latest version of WAMP (2.2c) on c:\wamp. The instructions I find on the net seem to be outdated in most cases and lacking the details I need to get things done right.
Guide: Openssl in WampServer 2.5
Prerequisite: There is normally no need to install openssl (it comes bundled with Wamp). Apache 2.4.9 includes 1.0.1g for instance.
System-Variable:
Open the Windows System panel ("WIN+Q" Search: system) > Advanced System Settings > Advanced > Environment variables
Add a new entry in system variables with name OPENSSL_CONF and its value being the path to openssl.cnf (usually somethings like C:\wamp\bin\apache\apache2.4.9\conf\openssl.cnf)
openssl folder structure:
In C:\wamp\bin\apache\apache#.#.#\conf create the following folder structure:
..
demoCA
|-----certs
|-----crl
|-----newcerts
|-----private
Configuring openssl.cnf:
I've followed Neil C. Obremski advice and cleared the following defaults:
countryName_default (was "AU")
stateOrProvinceName_default (was "Some-State")
0.organizationName_default (was "Internet Widgits Pty Ltd")
organizationalUnitName_default (was already empty)
Creating the certificate:
From command line browse to C:\wamp\bin\apache\apache#.#.#\bin\ and call "openssl req -new -out cacert.csr -keyout cacert.pem". If prompted enter a password and after that the DN informations like below.
Loading 'screen' into random state - done
Generating a 1024 bit RSA private key
.......................++++++
....++++++
writing new private key to 'cacert.pem'
Enter PEM pass phrase: my_secret_pass
Verifying - Enter PEM pass phrase: my_secret_pass
`-----
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) []:
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:local
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
C:\wamp\bin\apache\apache2.4.9\bin>
In the same console window now use "openssl rsa -in cacert.pem -out cacert.key" and if asked enter the password previously entered.
Enter pass phrase for cacert.pem: my_secret_pass
writing RSA key
Remove the ".rnd" file in C:\wamp\bin\apache\apache2.4.9\bin
Still in the same window call "openssl x509 -in cacert.csr -out cacert.cert -req -signkey cacert.key -days 365". If you experience the following error "unable to write 'random state'". This is a known bug! To workaround this call "set RANDFILE=.rnd" and retry the previous command.
Congrats you are now the owner of a self signed certificate!
I've placed the built files (they are currently in bin folder) according this Site:
cacert.pem, cacert.key in C:\wamp\bin\apache\apache#.#.#\conf\demoCA\private
cacert.cert, cacert.csr in C:\wamp\bin\apache\apache#.#.#\conf\demoCA\certs
In httpd.conf enable SLL (search for "#Include conf/extra/httpd-ssl.conf") + alter the following entries in httpd-ssl.conf:
SSLSessionCache "shmcb:C:/wamp/logs/ssl_scache(512000)"
DocumentRoot "C:/wamp/www"
#ErrorLog
#TransferLog
SSLCertificateFile "C:/wamp/bin/apache/apache2.4.9/conf/demoCA/certs/cacert.cert"
SSLCertificateKeyFile "C:/wamp/bin/apache/apache2.4.9/conf/demoCA/private/cacert.key"
CustomLog "C:/wamp/logs/ssl_request.log" \
Now test your Apache installation by calling httpd -t.
If you get the following error "SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?)." enable the following entry "LoadModule socache_shmcb_module modules/mod_socache_shmcb.so" in httpd.conf
Wamp is now configured with https support :-)
I've also enabled "LoadModule status_module modules/mod_status.so" using the following configuration in httpd.conf:
<IfModule status_module>
ExtendedStatus On
<Location /server-status>
SetHandler server-status
</Location>
</IfModule>
You can check now your server status here
https://localhost/server-status/
Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12 Server at localhost Port 443
Notes:
I've made this tute while trying to get it working on my machine (this was my first attempt in using OpenSSL on windows/wamp).
This guide is not meant for production systems!
You might have to change a few things like names depending on your openssl.cnf
My intention was not to make the best tutorial around but instead to simply note all required changes to get SSL working in WAMP.
Make sure to set the right -days amount for your x509 certificate
I finally know why NSA can easily break into servers with such a complex process :D
Since Wamp bundles apache together with OpenSSL it might be better to separately install it??
I have WAMP 2.2E installed.
I ran into the same problem, and after about an hour of searching the internet and trying all sorts of things, I stumbled into discovering that openssl can be enabled by:
Clicking on the WAMP icon in the system tray,
Hovering on "PHP",
Then "PHP extensions",
Then looking very carefully for "php_openssl" in the long list of extensions.
After following the excellent instructions from KAGRAN22, I ran into 2 errors:
AH00526: Syntax error on line 48 of C:/wamp64/bin/apache/apache2.4.9/conf/extra/httpd-ssl.conf:
Invalid command 'SSLCipherSuite', perhaps misspelled or defined by a module not included in the server configuration
That error is resolved by uncommenting this line
LoadModule ssl_module modules/mod_ssl.so
in httpd.conf.
Next I got this:
AH00526: Syntax error on line 74 of C:/wamp64/bin/apache/apache2.4.9/conf/extra/httpd-ssl.conf:
SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).
Which is resolved by uncommenting this line
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
in httpd.conf.
It should all work after that.
Facts:
It is not possible to configure SSL on WampServer Version 2.4 at least not in reasonable amount of time.
Normal person shouldn't be interested in dealing with this, because this is not practical nor normal way to do things.
SSL on Wamp is basicaly SM machine so if you have some masochistic needs please proceed with this.