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.
Related
I have microK8S cluster, and expose the API server at my domain.
The server.crt and server.key in /var/snap/microk8s/1079/certs need to be replaced with the ones that include my domain.
Otherwise, as expected, i get the error:
Unable to connect to the server: x509: certificate is valid for kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local, not mydonaim.com
With the help of cert-manager I have produced certificates and replaced them, my system works well.
Problem: every time server is restarted, server.crt and server.key are generated again in
/var/snap/microk8s/1079/certs. My custom certs are deleted, making API server unreachable remotely.
How can I stop the system from doing that all the time?
Workaround?
Should I place my certificates elsewhere and edit config files like /var/snap/microk8s/1079/args/kube-controller-manager with the path to those certificates? Are those config files auto-replaced as well?
Cluster information:
Kubernetes version: 1.16.3
Cloud being used: Bare metal, single-node
cluster Installation method: Ubuntu Server with Snaps
Host OS: Ubuntu 18.04.3 LTS
It looks like there is an existing issue that describes copying and modifying the /var/snap/microk8s/current/certs/csr.conf.template to include any extra IP or DNS entries for the generated certificates
Please be aware of the proposed updates in https://discuss.kubernetes.io/t/services-and-ports/11263/6. The following command was required to run in my env:
sudo microk8s refresh-certs
We have an Microsoft Active Directory Domain with a large pool of domain controllers (DC) that are are setup with LDAP. These are all setup with LDAPS and uses Certificate Services via a template to setup a certificate with the domain name (i.e. test.corp) in the Subject Alternate Name (SAN) for the LDAPS server to serve.
Since these are DC's, DNS is setup in a pool for each these systems to respond to requests to test.corp in a round robin fashion.
Each of these DC's have multiple templates and multiple certificates in the Local Computer\Personal Certificate Store.
Upon testing, using a nodejs module, ldapjs when making a LDAPS request using the domain name, test.corp we notice that a handful of servers fail with the following message:
Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match
certificate's altnames: Host: test.corp. is not in the cert's
altnames: othername:, DNS:.test.corp
As we investigated we found that these handful of LDAPS servers are serving the incorrect certificate. We determined this by using the following command
openssl s_client -connect .test.corp:636
If you take the certificate section of the output and put it in a file and use a tool such as the Certificate manager or certutil to read the file, you can see the certificate is not the correct one. (It does not have the domain "test.corp" SAN). We also verified this by comparing the Serial Numbers
As we investigated, since we have DC's that have multiple certificates in the Local Computer\Personal Certificate store, we came across the following article:
https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx
It suggests putting the certificate from the local computer\Personal certificate store to the Active Directory Domain Service\Personal store. We followed the steps outlined but we found the same results.
Upon further investigation, it was suggested to use a tool called ldp or adsiedit. We then proceeded to use these tools and spoofed the local machine's host file we were doing the test from, to point the domain (test.corp) to the ip's of one of the DC's that are giving us trouble. After a restart to clear any cache we tested the "ldp" and "adsiedit" tools to connect to test.corp. These systems did not report any errors.
We found this odd, we then ran the openssl command to see what certificate it was serving from this same system and we found it was still serving the incorrect certificate.
Upon further research, it appears that the "ldp" upon selecting the SSL checkbox and "adsiedit" tools were not compliant with RFC6125, specifically B.3
https://www.rfc-editor.org/rfc/rfc6125#appendix-B.3
, which basically states the identity of the certificate must match the identity of the request otherwise the handshake would fail. This identity verification is done by using the certificate common name (CN) or the SAN.
Based on this appears the tools "ldp" and "adsiedit" are not conforming to the RFC6125 standard.
All this to say, we need to first fix the handful of domain controllers that are serving the correct certificate. We are open to suggestions since we have been working on this problem for the past few months. Second, is there a way to get the MS tools in question to work to the RFC6125 standard?
This has been moved to:
https://serverfault.com/questions/939515/ldaps-microsoft-active-directory-multiple-certificates-rfc6125
RFC6125 specifically states that it does not supersede existing RFCs. LDAP cert handling is defined in RFC4513. Outside of that, RFC6125 has significant flaws. See also https://bugzilla.redhat.com/show_bug.cgi?id=1740070#c26
LDP will supposedly validate the SSL against the client store if you toggle the ssl checkbox on the connection screen.
That said, I'm not surprised that neither it nor ADSI edit enforce that part of the standard given they are often used to configure or repair broken configurations. Out of the box and without Certificate Services they use self signed certs on LDAPS. I would wager 80% of DCs never get a proper certificate for LDAP. If they enforced it most wouldn't be able to connect. A better design decision would have been to toggle off the validation.
I use a similar openssl command to verify my own systems. I think it's superior to LDP even if LDP were to validate the certificate. To save you some effort, I would suggest using this variant of the openssl command:
echo | openssl s_client -connect .test.corp:636 2>/dev/null | openssl x509 -noout -dates -issuer -subject -text
That should save you having to output to a file and having to read it with other tools.
I've found LDAPS on AD to be a huge pain for the exact reasons you describe. It just seems to pick up the first valid cert it can find. If you've already added it to the AD DS personal store, I'm not sure where else to suggest you go other than removing some of tother certs from the DCs computer store.
I'm trying to renew my SSL certificate but there is some problem i'm probably missing. after i'v done the following steps the server keep using the old certificate and i do'nt know why.
here'w what i have done:
Create new csr file (domain.csr) + key file (domain.key)
openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr
Copy csr file content and paste it to my ssl provider + get approval.
get 5 files from them and upload them to the server (domain.der,domain.pem
,domain.cer, chain.cer , domain.p7b )
set on apache ssl.conf file ,
SSLCertificateFile (domain.cer) SSLCertificateKeyFile (domain.key).
restart apache
for some reason my server is still using my old certificate.
is the something i'm doing wrong?
Well you figured it out yourself but in case anyone else is in same situation, here's some of the things you can check.
First up check locally whether this works, by running the following openssl command on the server (a crucial step we skipped!):
openssl s_client -connect localhost:443
This will show the cert presented to the client from Apache. If that's not the right one, then you know Apache config is at fault. If it is the right one then something downstream is a problem.
In your case you terminate SSL at the load balancer and forgot to change the cert there. Another issue could be browser caching the SSL cert (restart it, Ctrl+F5 to force refresh or better yet try another browser or a third party website like ssllabs.com).
Assuming it's a problem with Apache then you need to check the config to check all instances of the cert have been replace. The below command will show all the vhosts and what config they are configured in:
/usr/local/apache2/bin/apachectl -S
Alternatively just use standard find and grep unix commands to search your Apache config for the old or new cert:
find /usr/local/apache2/conf -name "*.conf" -exec grep olddomain.cer {} \; -print
Both those commands assume apache is installed in /usr/local/apache2 but change the path as appropriate.
If all looks good and you've definitely restarted Apache then you can try a full stop and restart as I have noticed sometimes a graceful restart of Apache doesn't always pick up new config. Before starting the web server back up again, check you can't connect from your browser (to ensure you're connecting to the server you think you're connecting to) and that the process is down with the following command:
ps -ef | grep httpd
and then finally start.
Another thing to check is that the cert you are installing is the one you think it is, using this openssl command to print out the cert details (assuming the cert is in x509 format but there are similar commands for other formats):
openssl x509 -in domain.cer -text
And last but not least check the Apache log files to see if any errors in there. Though would expect that to mean no cert is loaded rather than just the old one.
Good answer from #Barry.
Another aspect is apache is not the front most web server. From this conversation. It is possible that there are other web servers in front of apache.
Something like - nginx. In our case it was AWS ELB. We had to change cert in ELB in order to change.
We had a similiar problem to what #Akshay is saying above.
In order for the server to update the certificates we had to run some commands for Google Cloud Compute Engine Load Balancer:
gcloud compute target-https-proxies update
Hope this helps someone that is using GCP for hosting apache.
After upgrading to Yosemite I am no longer able to use my web server. It was set up to accept SSL connections on port 443, but now netstat -a -n says it isn't even listening on that port. I looked in /etc/apache2 and noticed that extra/ had been moved to original/extra so I moved that back. There was also a copy of httpd.conf in original/ but the timestamp and size was unchanged and diff showed it was identical to my original httpd.conf. The only other file in /etc/apache2 which has a new timestamp is users/ but nothing in that directory is changed.
All my certificate files in ssl/ still have the correct permissions. I don't see anything in /var/log/apache2/error_log (aside from the normal startup messages). In fact, even if I try to access the web server on port 80 I get nothing in either error_log or access_log even though I unexpectedly get 403 Forbidden on every page I try to access.
I have read about problems with Yosemite updating Apache from 2.2 to 2.4, but my web server doesn't even seem to be functional to the point of fixing any error caused by that. In any case, I did try the solution here, but my httpd.conf file does not contain any Order or Allow lines (nor does any file in extra/) so I can't try the answer suggested there.
OK, this is an old topic, but here's an answer.
I believe you have to uncomment a few lines in httpd.conf.
Run:
sudo vi /etc/apache2/httpd.conf
Uncomment the following lines:
#LoadModule ssl_module libexec/apache2/mod_ssl.so
#Include /private/etc/apache2/extra/httpd-ssl.conf
A simple trick is to search the configuration file using VIM to find lines related to SSL and debug from there.
In VIM, the following will find all instances of ssl... press n to go to next found instance:
?ssl
Once you made changes, test your configuration using:
sudo apachectl configtest
If all is good, run:
sudo apachectl restart
If you get the following error:
SSLCertificateFile: file '/private/etc/apache2/server.crt' does not exist or is empty
Create a default self-signed SSL certificate:
cd /private/etc/apache2
openssl req -new -x509 -days 365 -nodes -out server.crt -keyout server.key
Enter localhost when asked for your Common Name.
Then run configtest and, if all is good, restart.
I'm not familiar with certificates and openldap. I'm trying to port someone elses work from an older OS to CentOS-6 with openldap-2.4.23. On the old OS, an ldap connection worked without issue. Now on CentOS-6, I get the following error when doing a simple bind:
TLS error -8179:Peer's Certificate issuer is not recognized.
My /etc/openldap/ldap.conf has a single line:
TLS_CACERTDIR /etc/openldap/certs
I tried commenting out that line and putting the following into the file but that didn't change the error message I received.
tls_reqcert allow
I also tried putting only the following line in ldap.conf but that didn't change the error. I tried this based on information found in this question.
LDAPTLS_CACERT /etc/ssl/certs/ca-bundle.crt
I copied files into the following directories:
/etc/pki/tls/certs/ca.crt
/etc/pki/tls/certs/server.crt
/etc/pki/tls/private/server.key
I have no choice but to use openldap-2.4.23. Any idea what is causing this error or what I can do to troubleshoot?
Thanks in advance.
SP
As per http://www.zytrax.com/books/ldap/ch6/ldap-conf.html TLS_CACERT should point to the file containing the CA cert that the client will use to verify the certificate. You need to make sure the your servers CA [The CA that signed your server certificate] is present in the file that TLS_CACERT points to[in your case /etc/ssl/certs/ca-bundle.crt.
I had the same error. In my case the reason was, that my client had the wrong certificate in /etc/ipa/ca.crt. To fix this, I just copied /etc/ipa/ca.crt from the KDC server to the client and the error disappeared.
Depending upon the environment, OpenLDAP may completely ignore the value set for TLS_CACERTDIR because evidently GnuTLS doesn't support that type of certificate store.
From the man page for ldap.conf(5)
TLS_CACERTDIR <path>
Specifies the path of a directory that contains Certifi‐
cate Authority certificates in separate individual files.
The TLS_CACERT is always used before TLS_CACERTDIR. This
parameter is ignored with GnuTLS.
In my case, I suspect that GnuTLS is in use, so TLS_CACERTDIR simply does nothing. Using TLS_CACERT pointed to a file containing the certificate of my server's signing CA seems to have done the trick.
I think https://serverfault.com/questions/437546/centos-openldap-cert-trust-issues is a much more complete answer.