AWS EC2 FTPS set up - amazon-web-services

I can connect to my server using normal FTP but not on FTPs (I believe I need a certificate) I have opened ports on the server:
22 ssh
20 - 21 tcp
50000 - 51000 tcp
tcp 990
I am using EC2, I am using vsftpd and set the .conf file like I think I ought to (I followed silicon dales tutorial).
Could anyone point me the right direction? Like how to get a certificate and where to put it etc and whether the .conf needs to be updated?
The error I currently get when trying to connect to port 990 from Filezilla is:
Connection attempt failed with "ECONNREFUSED - Connection refused by server".

It could be your SecurityGroups.
Based on this DigitalOcean post, it looks like you have to open port range 40000-50000 for vsftpd.

Issue solved: I did it by using these commands on the server:
mkdir -p /etc/vsftpd/ssl
cd /etc/vsftpd/ssl
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout vsftpd-private.pem -out vsftpd-cert.pem
I also edited the vsftpd.conf file adding:
one_process_model=no
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH
rsa_cert_file=/etc/vsftpd/ssl/vsftpd-cert.pem
rsa_private_key_file=/etc/vsftpd/ssl/vsftpd-private.pem

Related

Postman how to send server SSL certificate client.crt

I want to convert the following curl into a Postman script:
curl --cacert ca.crt --key client.key --cert client.crt "https://myurl"
All three SSL parts are required, i.e. client cert, client key AND server cert.
In Postman settings - certificates, I can set the CLIENT crt and the client KEY....but how do I set the server cert that is also required otherwise the request will fail.
To resolve this I converted ca.crt, client.key and client.crt into a .pfx file using this command:
openssl pkcs12 -export -out certificate.pfx -inkey client.key -in client.crt -certfile CA.crt
This created a file called certificate.pfx
[You will be prompted whether you want to add a password for the file or not].
Open Postman – click on the settings cog and then choose Settings
Click on Certificates
Click on ‘Add Certificate’ to the right of Client Certificates
In the Host section set the url as required for your API
In the PFX file section click on Select File and browse to certificate.pfx
If you created a password for certificate.pfx - enter that in the Passphrase section
Click on ‘Add’
Close Settings
You should now be able to send the request to the API and get a successful response

Mosquitto MQTT service failed to restart after adding SSL configuration

I'm trying to configure SSL access to my mosquitto bridrge on Amazon EC2, Ubuntu 18 server. I followed the steps described in mosquitto tls docs and ended up with the following files:
ca.crt
ca.key
ca.srl
client.crt
client.csr
client.key
server.crt
server.csr
server.key
in a temporary directory.
Then I copied three files:
sudo cp ca.crt /etc/mosquitto/ca_certificates/
sudo cp server.key /etc/mosquitto/certs/
sudo cp server.crt /etc/mosquitto/certs/
Then I added the following section to the configuration file:
listener 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
keyfile /etc/mosquitto/certs/server.key
certfile /etc/mosquitto/certs/server.crt
Then I wanted to restart mosquitto:
sudo service mosquitto restart
This doesn't work and responds with
> Job for mosquitto.service failed because the control process exited with error code.
> See "systemctl status mosquitto.service" and "journalctl -xe" for details.
I tried both and there was just information, that the configuration is wrong.
I tried commenting out different lines and the following structure let's the service restart:
listener 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
keyfile /etc/mosquitto/certs/server.key
#certfile /etc/mosquitto/certs/server.crt
Unfortunatelly, the certfile is nessesary for the configuration to work. I checked the example configuration and the docs, and the certfile is a legal and required parameter.
How can I solve this issue?
I'm running Mosquitto on Ubuntu server. I ran also into Mosquitto failing to start after adding SSL certificates and configuration. I got a standalone certificate from Let’s Encrypt by Certbot tool.
Version information:
Ubuntu 18.04.5 LTS,
Mosquitto 2.0.4. (MQTT v5.0/v3.1.1/v3.1 broker) and
Certbot 1.11.0.
In original and failing configuration the mosquitto was configured to use certificates in /etc/letsencrypt... location.
My solution was to move all certificate files from /etc/letsencrypt/archive/ into /etc/mosquitto/ -folder and make the respective certificate file pointers in mosquitto configuration to point to this location.
Most relevant debugging for the problem in the trouble shooting is available in the logfile /var/log/mosquitto/mosquitto.log file.*
Further info about troubleshooting
Playing around with ownerships did not have any effect, in this case. The final configuration with certificates in /etc/mosquitto/certs folder worked regardless if the owner of the files and certificate containing folder was mosquitto or root.
I also tried not using the symbolic links of .../live/... and tested using directly the files in /etc/letsencrypt/archive/... location instead, did not work.
I did not check if some individual file is causing the issue, just moved them all. Tried afterwards to symlink from ..mosquitto/certs one of the files only to note that mosquitto will fail to start. For this server set-up to run, I need to keep the certificate files in ...mosquitto/certs folder".
Changing the certificate/key permissions fixed the issue for me.
E.g.
sudo chmod 744 raspberrypi.crt
sudo chmod 644 raspberrypi.key
As per this forum:-
https://github.com/owntracks/tools/issues/6

how to use ssl certificates in openssl with gsoap, using a c++ client/server

I am using gsoap and openssl under Visual Studio C++, I created a client and a server on localhost (port 443).
I have a non explicit error without any description when using (from client side) the option:
soap_ssl_client_context(&soap, "SOAP_SSL_DEFAULT"...
but if I use it with the option:
soap_ssl_client_context(&soap, SOAP_SSL_DEFAULT | SOAP_SSL_SKIP_HOST_CHECK, ...
it is working correctly (but insecurely I gess).
So I decided to check what is the error by checking packets on localhost (with raw capture), and I see that the communication ends by an Encrypted Alert (21) after terminating the handshake.
And I Wonder what I need to do, to get this application working properly and securely on localhost (for testing purpose).
More Info:
I have generated ssl certificates for server side with a batch:
echo CREATE SERVER CA and CA CERT
echo Generate Private Key (passwd protected)
openssl genrsa -des3 -out .\private\CA_key.pem 2048
pause
echo Generate server CA
echo use your server name for the 'common name' field!
openssl req -out ca.pem -new -x509 -key .\private\CA_key.pem
pause
echo Create certificate signing request for CA pub Key
openssl req -new -key .\private\CA_key.pem -out CA_csr.pem
pause
echo Sign it
openssl req -in CA_csr.pem -out CA_crt.pem -key .\private\CA_key.pem -x509 -days 3020
pause
echo FOR C++ SERVER ONLY
type .\private\CA_key.pem CA_crt.pem > server.pem
pause
And also for client side:
echo CREATE PUB/PRIV key pair and cert for client
echo Generate key pair
openssl genrsa -des3 -out client_key.pem 2048
pause
echo Create CSR for client pub key
openssl req -new -key client_key.pem -out client_csr.pem
pause
echo User ca to sign the request (need serial file with '01')
echo make sure your openssl.cnf is correct (path and right CA certificate file)
openssl ca -in client_csr.pem -out client_crt.pem -config openssl.cfg -days 1825
pause
echo CLIENT SPECIFIC FORMATING (optional)
echo for C++ clients ONLY
type client_key.pem client_crt.pem > LCC.pem
I used:
CA_crt.pem as "cacert file" in both soap_ssl_server_context and soap_ssl_client_context.
LCC.pem as client key, and server.pem as server key.
I am not sure if all certificate generation steps are correct but it is working with the option (SOAP_SSL_DEFAULT | SOAP_SSL_SKIP_HOST_CHECK).
Can you help me please to find out what is missing to get it working with SOAP_SSL_DEFAULT only ?
Thank you
I am not sure if all certificate generation steps are correct but it is working with the option (SOAP_SSL_DEFAULT | SOAP_SSL_SKIP_HOST_CHECK).
If the certificate works with gSoap with SOAP_SSL_SKIP_HOST_CHECK and does not work without it, then the CommonName for your certificate is not a hostname or IP address. Depending on the purpose for your certificate, you may not want your certificate CommonName to be the host ip/name and so using SOAP_SSL_SKIP_HOST_CHECK is fine.
If you want to quit using the SOAP_SSL_SKIP_HOST_CHECK flag, then regenerate your certificate to have the CommonName be the host name or ip address. (Note: You may run into conflicts with other certificates installed on your system - if one of them has an identical CommonName.)

c++ thrift client not working with ssl (SSL_connect hangs)

I wanted to use ssl support provided by thrift in my c++ server and client. My own thrift client was always hanging in SSL_connect after it passes through "transport->open()"
. So I built the official thrift\thrift-0.9.1\test\cpp\src\TestServer.cpp and testclient.cpp for windows. Same thing happened to me here as well.
I really could use any help or pointers.
Update:
I also tried using the latest sources at https://github.com/apache/thrift
Before I was working with 0.9.1
Since I saw testserver.cpp was doing the following
sslSocketFactory->loadCertificate("./server-certificate.pem");
sslSocketFactory->loadPrivateKey("./server-private-key.pem");
sslSocketFactory->ciphers("ALL:!ADH:!LOW:!EXP:!MD5:#STRENGTH");
and the testclient.cpp was doing the following
factory->ciphers("ALL:!ADH:!LOW:!EXP:!MD5:#STRENGTH");
factory->loadTrustedCertificates("./trusted-ca-certificate.pem");
factory->authenticate(true);
So I took following steps to build the certs
openssl genrsa -out ca-private-key.pem 2048
openssl req -new -x509 -nodes -days 3600 -key ca-private-key.pem -out ca-certificate.pem
openssl req -newkey rsa:2048 -days 3600 -nodes -keyout server-private-key.pem -out server-request.pem
openssl rsa -in server-private-key.pem -out server-private-key.pem
openssl x509 -req -in server-request.pem -days 3600 -CA ca-certificate.pem -CAkey ca-private-key.pem -set_serial 01 -out server-certificate.pem
Output for different test cases-
TestServer.exe --ssl
TestClient.exe --host 192.168.0.4 --ssl
I saw TestClient.exe hang on SSL_connect while running
testClient.testVoid();
During hang server side callstack
During hang client side callstack. Clearly both sides are stuck reading!
Wireshark debug trace for the above mentioned client server communication.
Debug output through "openssl s_client" run against thriftserver-
openssl s_client -connect 192.168.0.4:9090 -state -debug
Loading 'screen' into random state - done
CONNECTED(00000100)
SSL_connect:before/connect initialization
write to 0x1e2b5c0 [0x1e2bf50] (321 bytes => 321 (0x141))
0000 - 16 03 01 01 3c 01 00 01-38 03 03 52 dc 25 39 ad ....<...8..R.%9.
SSL_connect:SSLv2/v3 write client hello A
TestServer.exe --ssl --server-type nonblocking
TestClient.exe --ssl
I saw TestClient.exe failed on SSL_connect (10054) while running
testClient.testVoid();
Server stderr was saying
Thrift: Sat Jan 18 19:31:21 2014 TNonblockingServer: frame size too large (369295616 > 268435456)
from client <Host: ::1 Port: 22869>. Remote side not using TFramedTransport?
openssl.exe s_client -connect localhost:9090 -state -debug
Loading 'screen' into random state - done
CONNECTED(0000018C)
SSL_connect:before/connect initialization
write to 0x6db5c0 [0x6dbf50] (321 bytes => 321 (0x141))
0000 - 16 03 01 01 3c 01 00 01-38 03 03 52 db 4b 8a dd ....<...8..R.K..
SSL_connect:SSLv2/v3 write client hello A
read from 0x6db5c0 [0x6e14b0] (7 bytes => -1 (0xFFFFFFFF))
SSL_connect:error in SSLv2/v3 read server hello A
write:errno=10054
TestServer.exe --ssl --server-type nonblocking --transport framed
TestClient.exe --ssl --transport framed
Server stderr was saying
Thrift: Sat Jan 18 19:36:01 2014 TNonblockingServer: frame size too large (36929
5616 > 268435456) from client <Host: ::1 Port: 23087>. Remote side not using TFramedTransport?
By stepping through I definitely confirmed that testclient was using framed transport.
I think I know what may be going on and might have discovered the bug.
After debugging further I saw that virtual function createSocket is declared with parameter "int"
boost::shared_ptr createSocket(int socket);
https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/transport/TSSLServerSocket.h
https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/transport/TSSLServerSocket.cpp
However the base class TServerSocket.h declare it as "THRIFT_SOCKET" which on windows is ULONG_PTR
virtual boost::shared_ptr createSocket(THRIFT_SOCKET client);
https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/transport/TServerSocket.h
Hence correct createSocket was not being called from the guts.
After making this change I am able to move forward which I confirmed again with openssl s_client -connect localhost:9090 -state -debug
I will send my patch to thrift dev in case they would like to accept it.

How can I test https connections with Django as easily as I can non-https connections using 'runserver'?

I have an application that uses "secure" cookies and want to test it's functionality without needing to set up a complicated SSL enabled development server. Is there any way to do this as simply as I can test non-encrypted requests using ./manage.py runserver?
It's not as simple as the built in development server, but it's not too hard to get something close using stunnel as an SSLifying middleman between your browser and the development server. Stunnel allows you to set up a lightweight server on your machine that accepts connections on a configured port, wraps them with SSL, and passes them along to some other server. We'll use this to open a stunnel port (8443) and pass along any traffic it receives to a Django runserver instance.
First you'll need stunnel which can be downloaded here or may be provided by your platform's package system (e.g.: apt-get install stunnel). I'll be using version 4 of stunnel (e.g.: /usr/bin/stunnel4 on Ubuntu), version 3 will also work, but has different configuration options.
First create a directory in your Django project to hold the necessary configuration files and SSLish stuff.
mkdir stunnel
cd stunnel
Next we'll need to create a local certificate and key to be used for the SSL communication. For this we turn to openssl.
Create the key:
openssl genrsa 2048 > stunnel.key
Create the certificate that uses this key (this will ask you a bunch of information that will be included in the certficate - just answer with whatever feels good to you):
openssl req -new -x509 -nodes -sha1 -days 365 -key stunnel.key > stunnel.cert
Now combine these into a single file that stunnel will use for its SSL communication:
cat stunnel.key stunnel.cert > stunnel.pem
Create a config file for stunnel called dev_https with the following contents:
pid=
cert = stunnel/stunnel.pem
sslVersion = SSLv3
foreground = yes
output = stunnel.log
[https]
accept=8443
connect=8001
TIMEOUTclose=1
This file tells stunnel what it needs to know. Specifically, you're telling it not to use a pid file, where the certificate file is, what version of SSL to use, that it should run in the foreground, where it should log its output, and that it should accept connection on port 8443 and shuttle them along to port 8001. The last parameter (TIMEOUTclose) tells it to automatically close the connection after 1 second has passed with no activity.
Now pop back up to your Django project directory (the one with manage.py in it):
cd ..
Here we'll create a script named runserver that will run stunnel and two django development servers (one for normal connections, and one for SSL connections):
stunnel4 stunnel/dev_https &
python manage.py runserver&
HTTPS=1 python manage.py runserver 8001
Let's break this down, line-by-line:
Line 1: Starts stunnel and point it to the configuration file we just created. This has stunnel listen on port 8443, wrap any connections it receives in SSL, and pass them along to port 8001
Line 2: Starts a normal Django runserver instance (on port 8000)
Line 3: Starts another Django runserver instance (on port 8001) and configures it to treat all incoming connections as if they were being performed using HTTPS.
Make the runscript file we just created executable with:
chmod a+x runserver
Now when you want to run your development server just execute ./runserver from your project directory. To try it out, just point your browser to http://localhost:8000 for normal HTTP traffic, and https://localhost:8443 for HTTPS traffic. Note that you're browser will almost definitely complain about the certificate used and require you to add an exception or otherwise explicitly instruct the browser to continue browsing. This is because you created your own certificate and it isn't trusted by the browser to be telling the truth about who it is. This is fine for development, but obviously won't cut it for production.
Unfortunately, on my machine this runserver script doesn't exit out nicely when I hit Ctrl-C. I have to manually kill the processes - anyone have a suggestion to fix that?
Thanks to Michael Gile's post and django-weave's wiki entry for the reference material.
I would recommend using the django-sslserver package.
The current package on PyPI only supports up to Django version 1.5.5 but a patch has been committed via 5d4664c. With this fix the system runs well and is a pretty simple and straightforward solution for testing https connections.
UPDATE:
Since I posted my answer the commit above has been merged into the master branch and a new release has been pushed to PyPI. So there shouldn't be any need to specify the 5d4664c commit for that specific fix.
just install
sudo pip install django-sslserver
include sslserver in installed aps
INSTALLED_APPS = (...
"sslserver",
...
)
now you can run
python manage.py runsslserver 0.0.0.0:8888
Similar to django-sslserver you could use RunServerPlus from django-extensions
It has dependencies on Werkzeug (so you get access to the excellent Werkzeug debugger) and pyOpenSSL (only required for ssl mode) so to install run:
pip install django-extensions Werkzeug pyOpenSSL
Add it to INSTALLED_APPS in your projects settings.py file:
INSTALLED_APPS = (
...
'django_extensions',
...
)
Then you can run the server in ssl mode with:
./manage.py runserver_plus --cert /tmp/cert
This will create a cert file at /tmp/cert.crt and a key file at /tmp/cert.key which can then be reused for future sessions.
There is a bunch of extra stuff included in django-extensions that you may find of use so it is worth having a quick flick through the docs.
Signup to https://ngrok.com/. You can use https to test. This might help people who just want to quickly test https.
One way is using ngrok.
Install ngrok.
download link: https://ngrok.com/download
Issue following command on terminal
ngrok http 8000
It will start ngrok session. It will list two urls. One is mapped to http://localhost:8000. Second is mapped to https://localhost:8000. Please check the screenshot below. Use either url. It will map to your local server.
Second method is as per the the solution provided by #EvanGrim. Link - https://stackoverflow.com/a/8025645/9384511
First method is preferred if you need to test https url just couple of times. But if your requirement says https is mandatory then it would be better if you follow second method.
I faced following issues with #EvanGrim solution
When accessing https url via requests, you will get subAltNames
missing warning. This should not be a problem. Your url should work
fine.
You will not be able to access https url via android volley. It will
throw error - your ip or localhost is not verified. Something like
that.
I solved these issues by adding subAltname to ssl certificate. Below is the steps I followed to run a local https server without the above two issues.
Install stunnel. stunnel version used is version4(/usr/bin/stunnel4) For ubuntu execute
sudo apt-get install stunnel
Create directory stunnel in your Django Project.
Copy openssl.cnf from /etc/ssl/openssl.cnf or /usr/lib/ssl/openssl.cnf to stunnel. Avoid editing them directly unless you know what you are doing.
Search for [ req ] or [req] section.In req section set
x509_extensions = v3_ca
req_extensions = v3_req
x509_extensions and req_extensions should be present. If not, add it. If commented, uncomment it.
Search for [v3_req] section. In this section add
subjectAltName = #alt_names
Search for [v3_ca] section. In this section add
subjectAltName = #alt_names
We need to add a new section alt_names. This can be added any where. I added after [v3_ca] section.
For local host and your ip address add as follows:
[alt_names]
DNS.1 = localhost
IP.1 = x.x.x.x
IP.2 = 127.0.0.1
To create key execute
openssl genrsa 1024 > stunnel.key
To create DER encoded certificate execute either first or second command
If you have directly edited /etc/ssl/openssl.cnf or /usr/lib/ssl/openssl.cnf
openssl req -new -x509 -nodes -sha1 -days 365 -key stunnel.key > stunnel.cert
If you have made copy of openssl.cnf in stunnel directory.
openssl req -new -x509 -nodes -sha256 -days 365 -key stunnel.key -config openssl.cnf > stunnel.cert
To create PEM ecoded certificate execute.
cat stunnel.key stunnel.cert > stunnel.pem
Create a config file for stunnel called dev_https.config with the following contents.
#not to use pid
pid=
#path of certificate file
cert = stunnel/stunnel.pem
#version of SSL to use
sslVersion = TLSv1.1
foreground = yes
#log output path
output = stunnel.log
[https]
#listen on port 8443
accept=8443
#tunnel the connection to port 8001
connect=8001
# and close connection automatically after one second
TIMEOUTclose=1
Please note sslVersion is based on OpenSSL version used by python interpreter. Mine is OpenSSL 1.1.1. For this version use TLSv1.1. Find out your openssl version and add corresponding version.
You can find out the OpenSSL version by executing
python -c "import ssl; print(ssl.OPENSSL_VERSION)"
Create a script called runserver and add below contents. This script should reside in same directory as manage.py
This script will run two stunnel and two django environment. One for http connections and one for https connections.
The issue of runserver not exiting cleanly(As mentioned by Evan) is solved by trap statement in which cleanup function is called.
stunnel4 stunnel/dev_https.config &
stunnel_pid=$!
echo "stunnel pid: $stunnel_pid"
python manage.py runserver 0.0.0.0:8000 &
py_server_bg=$!
echo "BG py server pid: $py_server_bg"
HTTPS=1 python manage.py runserver 0.0.0.0:8001
function cleanup()
{
echo "Cleaning up"
kill $stunnel_pid
kill $py_server_bg
echo "Cleaned"
}
trap cleanup EXIT
Execute
chmod a+x runserver
From you django project execute
./runserver
Now if you execute a python requests command, subjectAltNames missing warning will not be displayed. Also your android volley https request will execute fine.
data = {'login_id':'someid'}
headers = {'content-type': 'application/json'}
url = "https://localhost:8443/myauth/check-id/"
r=requests.post(url, data=json.dumps(data), headers=headers,verify='stunnel/stunnel.pem')
I would like to thank #EvanGrim for the solution. And Thanks to #Friek, #Utku and #dr. Sybren. Based on their comments I implemented cleanup function.
It can be done in one line with socat:
socat openssl-listen:8443,fork,reuseaddr,cert=server.pem,verify=0 tcp:localhost:8000
, where 8443 is a port to listen for incoming HTTPS connections, server.pem is a self-signed server certificate and localhost:8000 is a debug HTTP server launched as usual.
More details: http://www.dest-unreach.org/socat/doc/socat-openssltunnel.html
For those looking for a foregrounded version of the stunnel option for debugging purposes:
stunnel.pem is a certificate generated as in Evan Grimm's top voted answer.
Listen on all local interfaces on port 443 and forward to port 80 on localhost
sudo stunnel -f -p stunnel.pem -P ~/stunnel.pid -r localhost:80 -d 443
sudo is only necessary for incoming ports (-d [host:]port) under 1024
Handle SSL/TLS with a proxy such as Nginx rather than Django. Nginx can be set up to listen on port 443 and then forward requests to your Django dev server (typically http://127.0.0.1:8000). An Nginx configuration for this might look like the following:
server {
listen 443 ssl;
server_name django-dev.localhost;
ssl_certificate /etc/ssl/certs/nginx_chain.pem;
ssl_certificate_key /etc/ssl/private/nginx.pem;
location / {
proxy_pass http://127.0.0.1:8000/;
proxy_set_header Host $host;
}
}
You'll also need to map django-dev.localhost to 127.0.0.1 and add django-dev.localhost to ALLOWED_HOSTS in settings.py. On Linux, you'll need to add the following line to /etc/hosts:
127.0.0.1 django-dev.localhost
You'll then be able to reach your dev site by going to https://django-dev.localhost in your browser (you will need to bypass your browser's security warning).
go to sslforfree.com and download certificate file
download 3246328748324897329847324234.txt file for verify
you need to add this in views.py
from django.http import HttpResponse
def read_file(request):
f = open('7263713672163767218367687767.txt', 'r')
file_content = f.read()
f.close()
return HttpResponse(file_content, content_type="text/plain")
after
add
urls.py
path('.well-known/pki-validation/', read_file)
install
pip install django-extensions
pip install pyOpenSSL
pip install werkzeug
./manage.py runserver_plus 0:443 --cert-file certificate.crt --key-file private.key
I have very simple solution for this, just follow below steps and you will be able to run your django project/app on https:// secure server.
step.1 install openssl on your system. you can get the executable file for installation at https://slproweb.com/products/Win32OpenSSL.html. I recommended you to install Win64 OpenSSL v1.1.1L (version) it is stable compare to 3.0.0
step.2 after successful installation navigate to C:\Program Files\OpenSSL-Win64\bin in our example. you can navigate to your installed directory where u have installed openssl, here you can find out openssl.exe run it as administrator.
step.3 Enter the following command to begin generating a certificate and private key:
req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
step 4: You will then be prompted to enter applicable Distinguished Name (DN) information, totaling seven fields, as you can see in below screenshot:
step 5: Once completed, you will find the certificate.crt and privateKey.key files created under the \OpenSSL\bin\ directory, like this
step 6: install django-sslserver in your system.
stpe 7: execute below command on your IDLE terminal:
python manage.py runsslserver --certificate C:/Program Files/OpenSSL-Win64/bin/cer
tificate.crt --key C:/Program Files/OpenSSL-Win64/bin/privateKey.key 127.0.0.1:8000
Congratulations now your django project is running on https.
I hope this will help you, if u face any difficulty feel free to ask.
Tried to add a comment to this answer, where he asks about killing the processes but the code formatting in comments is limited. Here is my modified runserver.bash
#!/bin/bash
# Script to kill previous instances of dev servers,
# then start the 2 dev servers, one of which is https.
#
cd "$(dirname "$0")"
echo $PWD
. bin/activate
if [[ "$1" =~ "kill" ]]; then
if [[ -n `ps -ef | egrep 'python manage.py runserver [1-9,\.]*' | grep -v grep | awk '{ print $2}'` ]]; then
kill -15 `ps -ef | egrep 'python manage.py runserver [1-9,\.]*' | grep -v grep | awk '{ print $2}'`
fi
else
if [[ -n `ps -ef | egrep 'python manage.py runserver [1-9,\.]*' | grep -v grep | awk '{ print $2}'` ]]; then
kill -15 `ps -ef | egrep 'python manage.py runserver [1-9,\.]*' | grep -v grep | awk '{ print $2}'`
fi
if [[ -z `ps -ef | egrep 'stunnel4 stunnel/dev_https' | grep -v grep | awk '{ print $2}'` ]]; then
stunnel4 stunnel/dev_https &
fi
python manage.py runserver 192.168.1.183:8006 &
HTTPS=1 python manage.py runserver 192.168.1.183:8001
fi
Based on Ryabchenko Alexander answer, this is how I do it in Django for local tests:
token_url = '{}/o/token/'.format(settings.BOQ_APP_URL)
oauth = OAuth2Session(
client=LegacyApplicationClient(client_id=settings.BOQ_APP_CLIENT_ID),
)
# disable cert verification for local tests
if settings.DEBUG:
oauth.verify = False
token = oauth.fetch_token(
token_url=token_url,
username=settings.BOQ_APP_USERNAME,
password=settings.BOQ_APP_PASSWORD,
client_secret=settings.BOQ_APP_CLIENT_SECRET,
)
print(token)