Haven't written program for quite long time, I am scratching my head for this one. I did some research first but nothing I find seems working in my case so far. So here's my task:
1) First command:
openssl s_client -crlf -quiet -connect email-smtp.us-east-1.amazonaws.com:465
which will open a separate shell(not sure if it's the correct terminology to called it shell yet that's what comes in to my mind) and output as follow'
bitnami#ip-172-31-49-138:~/script$ openssl s_client -crlf -quiet -connect email-smtp.us-east-1.amazonaws.com:465
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4
verify error:num=20:unable to get local issuer certificate
220 email-smtp.amazonaws.com ESMTP SimpleEmailService-1866227133 zmydXvw5oa7oYxVcuSDr
2) now enter the 2nd command: EHLO ip-172-31-49-138
which yields the following output --
bitnami#ip-172-31-49-138:~/script$ openssl s_client -crlf -quiet -connect email-smtp.us-east-1.amazonaws.com:465
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4
verify error:num=20:unable to get local issuer certificate
220 email-smtp.amazonaws.com ESMTP SimpleEmailService-1866227133 zmydXvw5oa7oYxVcuSDr
EHLO ip-172-31-49-138
250-email-smtp.amazonaws.com
250-8BITMIME
250-SIZE 10485760
250-AUTH PLAIN LOGIN
250 Ok
so I need to write a bash script to automate those two commands(there're more commands but for simplicity I only list the first two).
no matter I use &, or grouping {}, or insert enter line, the script will always execute the first command first, which seems waiting for something until time out, then called the 2nd command at which point the system will not recognize it because it only available while still in the shell bring up by the first command:
bitnami#ip-172-31-49-138:~/script$ ./sendMail
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4
verify error:num=20:unable to get local issuer certificate
220 email-smtp.amazonaws.com ESMTP SimpleEmailService-1866227133 CuOz95oNth2yafnNOxp4
421 Timeout waiting for data from client.
./sendMail: line 3: EHLO: command not found
bitnami#ip-172-31-49-138:~/script$
Hope someone can shed some light into it.
Your second "command" isn't a command at all - it's input to your first command. As such, you need to pipe it in. The following will work:
echo EHLO ip-172-31-49-138 | openssl s_client -crlf -quiet -connect email-smtp.us-east-1.amazonaws.com:465
Related
I'm trying to log into an ftps site. I've tried giving the login creds at the command line (and putting set parameters in ~/.lftprc, then opening an lftp session and typing those parameters with lftp job control statements. Regardless, I keep hitting the same roadblock:
421 Sorry, cleartext sessions are not accepted on this server.
Please reconnect using SSL/TLS security mechanisms.
I got furthest with the following parameters, but keep getting the error above.
How do I get lftp to use SSL/TLS security mechanism from the command line?
The objective is to script the access to this ftps site using bash (programming without using expect).
lftp
lftp :~> set ssl-allow false
lftp :~> set passive-mode yes
lftp :~> open ftp.abc.com
lftp ftp.abc.com:~> login theuser
Password:
lftp theuser#ftp.abc.com:~> cd
`cd' at 0 [Delaying before reconnect: 26]
CTRL-C
lftp theuser#ftp.abc.com:~> debug
lftp theuser#ftp.abc.com:~> cd
---- Connecting to ftp.abc.com (XX.XXX.XX.XX) port 21
<--- 220-Welcome to the Yahoo! Web Hosting FTP server
<--- 220-Need help? Get all details at:
<--- 220-http://help.yahoo.com/help/us/webhosting/gftp/
<--- 220-
<--- 220-No anonymous logins accepted.
<--- 220-Yahoo!
<--- 220-Local time is now 15:30. Server port: 21.
<--- 220-This is a private system - No anonymous login
<--- 220 You will be disconnected after 5 minutes of inactivity.
---> FEAT
<--- 211-Extensions supported:
<--- EPRT
<--- IDLE
<--- MDTM
<--- SIZE
<--- MFMT
<--- REST STREAM
<--- MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
<--- MLSD
<--- XDBG
<--- AUTH TLS
<--- PBSZ
<--- PROT
<--- TVFS
<--- ESTA
<--- PASV
<--- EPSV
<--- SPSV
<--- ESTP
<--- 211 End.
---> OPTS MLST type;size;modify;UNIX.mode;UNIX.uid;UNIX.gid;
<--- 200 MLST OPTS type;size;sizd;modify;UNIX.mode;UNIX.uid;UNIX.gid;unique;
---> USER theuser
<--- 421 Sorry, cleartext sessions are not accepted on this server.
Please reconnect using SSL/TLS security mechanisms.
It seems like lftp is not configured correctly on many systems, which makes it unable to verify server certificates (producing Fatal error: Certificate verification: Not trusted).
The web (and answers in this post) is full of suggestions to fix this by disabling certificate verification or encryption altogether. This is unsecure as it allows man-in-the-middle attacks to pass unnoticed.
The better solution is to configure certificate verification correctly, which is easy, fortunately. To do so, add the following line to /etc/lftp.conf (or alternatively ~/.lftp/rc, or ~/.config/lftp/rc):
set ssl:ca-file "/etc/ssl/certs/ca-certificates.crt"
ca-certificates.crt is a file that contains all CA certificates of the system. The location used above is the one from Ubuntu and may vary on different systems. To generate or update the file, run update-ca-certificates:
sudo update-ca-certificates
If your system does not have this command, you can create one manually like this:
cat /etc/ssl/certs/*.pem | sudo tee /etc/ssl/certs/ca-certificates.crt > /dev/null
lftp :~> set ssl-allow false
You've explicitly set ssl-allow to false. But this must be true if lftp should attempt to use SSL.
You might also need to
set ssl:verify-certificate no
My answer provides access for a single user on your system rather than a system-wide certificate.
lftp uses Transport Layer Security (TLS). So it’s essential to first grab the certificate from the FTP server.
openssl s_client -connect <ftp-hostname>:21 -starttls ftp
I include the entire certificate chain in a new file called cert.crt in my local ~/.lftp folder. At the very least, you're looking to include all the text of the certificate itself: -----BEGIN CERTIFICATE----- <...> -----END CERTIFICATE-----.
I create a file called rc in the local ~/.lftp folder and add the lines
set ssl:ca-file “cert.crt”
set ssl:check-hostname no (this prevents Fatal error: Certificate verification: certificate common name doesn't match requested host name ‘<ftp-hostname>’ when running a command like ls remotely)
Setting ftp:ssl-allow true didn't work for me.
By typing set:
lftp :~> set
I noticed this:
set ftp:ssl-allow true
set ftp:ssl-allow/XXX.XXX.XXX.XXX no
with XXX.XXX.XXX.XXX being the server, I was logging into.
So the final set of commands I needed was:
lftp :~> set ftp:ssl-allow true
lftp :~> set ftp:ssl-allow/XXX.XXX.XXX.XXX true
lftp :~> set ssl:verify-certificate no
lftp version must be >= 4.6.3 (Debian user)
What worked for me step by step with lftp:
get certificate of host with openssl s_client -connect <ftp_hostname>:21 -starttls ftp, at the begining of result I got something like -----BEGIN CERTIFICATE-----
MIIEQzCCAyu.....XjMO
-----END CERTIFICATE-----
copy that -----BEGIN CERTIFICATE-----
MIIEQzCCAyu.....XjMO
-----END CERTIFICATE----- into /etc/ssl/certs/ca-certificates.crt
Into lftp configuration reference this certificate file adding to /etc/lftp.conf for systemwide set ssl:ca-file "/etc/ssl/certs/ca-certificates.crt"
and then do your sync or whatever with lftp, on my case it is lftp -u "${FTP_USER},${FTP_PWD}" ${FTP_HOST} -e "set net:timeout 10;mirror ${EXCLUDES} -R ${LOCAL_SOURCE_PATH} ${REMOTE_DEST_PATH} ; quit"
This worked for me for a FTPS server connection (with port 990, but not necessary to specify) using lftp
code:
lftp ftps://USER:PASSWORD#server.com -c "set ssl:verify-certificate false;"
then:
do stuff
more info at:
how-to-avoid-lftp-certificate-verification-error
I have a leaf cert, intermediate cert, and a root cert.
client.crt contains all three, by way of cat leaf.crt intermediate.crt root.crt > client.crt
$ # Fails
$ openssl.exe verify client.crt
C = US, ...
error 20 at 0 depth lookup: unable to get local issuer certificate
error client.crt: verification failed
$ # Passes, as expected, since it has the whole chain
$ openssl.exe verify -CAfile client.crt client.crt
client.crt: OK
$ # Add intermediate and root to stores
$ certutil.exe -addstore -f "ROOT" .\root.crt
CertUtil: -addstore command completed successfully.
$ certutil.exe -addstore -f "CA" .\intermediate.crt
CertUtil: -addstore command completed successfully.
$ # Both client.crt and leaf.crt fail to verify
$ openssl.exe verify client.crt
C = US, ...
error 20 at 0 depth lookup: unable to get local issuer certificate
error client.crt: verification failed
$ openssl.exe verify leaf.crt
C = US, ...
error 20 at 0 depth lookup: unable to get local issuer certificate
error leaf.crt: verification failed
It appears as if openssl.exe is not picking up the certs I install. I've also gone through and installed these through the Windows certificate manager to no avail.
How do I get openssl to pick up this CA chain?
I want to import CA certificate into a Java keystore.
I found this answer with some Unix commands.
I understand that keytool works in Windows the same way as in Linux, doesn't it?
But what about openssl?
I installed openssl in Windows, then ran it and it works normally. But how can I replace a code below?
</dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ${HOST}.cert
Or can I replace openssl with something else?
Probably the easiest way is to use KeyStore Explorer. Just use the "Examine SSL" feature and then click on "Import":
Alternatively you can replace </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ${HOST}.cert with manual steps. If you execute
openssl s_client -connect -connect www.google.com:443
it will output something like this:
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEgjCCA2qgAwIBAgIIZ20sUt50wGgwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
...
htkxJVFaLUXScpkNQagWzehkj9BGdV4oztKMgTU8hcZEsiDKF0aZmaMfAXAF6u0r
0n9sKu3Ap0uSR0+G4PVDcJkJzw2UiUsu8IkkHy3HjKt4zCCrATjZ4FPgtFHSWv8d
ZmUdWJhgJ30s/EvOKn1uQ6QlPWaCJKc9W6JaJQTX6PjPDMs0sK90ss9vCIJ0dDw5
ud+EC4cT
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
---
No client certificate CA names sent
Mark the lines starting with -----BEGIN CERTIFICATE----- up to -----END CERTIFICATE----- and copy them into a text editor. Save it as [host].crt. Then execute the keytool command.
If you want to automate these steps in a script, you'll have to install Cygwin or one of the suggestions in this answer here.
I'm trying to create a self sign certificate by makecert Here is what I do:
makecert -n "CN=TuyenTk CA, C=VN, ST=Hanoi, L=Hoan Kiem" -cy authority
-h 1 -a sha1 -sv "D:\TuyenTk CA.pvk" -r "D:\TuyenTk CA.cer"
makecert -n "CN=TuyenTk" -ic "D:\TuyenTk CA.cer" -iv "D:\TuyenTk CA.pvk"
-eku "1.3.6.1.5.5.7.3.3" -cy end -a sha1 -h 0 -sky exchange -pe "D:\TuyenTk.cer"
pvk2pfx -pvk "D:\TuyenTk CA.pvk" -spc "D:\TuyenTk CA.cer"
-pfx "D:\TuyenTk.pfx" -pi "myPassWord"
The first line is make self sign cert (CA cert), The second line is use CA cert sign other cert, and the last is generate pfx file to sign the exe file.
Though all above 3 commands is reported success, when I double click to TuyenTk CA.cer and TuyenTk.cer, in the Details tab windows tell that the basic constraints is critical. So when I use the TuyenTk.pfx file to sign my exe file, in the Digital Signatures Tab, the certificate is not valid: a certificate basic constraints extension has not been observed
I view cert's details before install it, and after install in trusted root or personal location of cert store, I still see the error.
How can I fix this problem? Thank!
To create your self-signed root CA certificate, try these options:
makecert -r -pe -m 1200 -len 2048 -n "CN=TuyenTk CA, C=VN, ST=Hanoi, L=Hoan Kiem" -ss CA -sr CurrentUser -a sha1 -sky signature -cy authority -sv "D:\TuyenTk_CA.pvk" "D:\TuyenTk_CA.cer"
I left off "-h 1" to give you unlimited signing depth in the basic constraints; some SSL packages don't like unlimited path lengths, so you can either have layers of keys or put in "-h 5" or whatever value you feel will serve your needs. Switches I added:
-pe Make private key exportable
-m 1200 Make CA key valid for 100 years (1200 months)
-ss CA This key goes into the CA certificate store
-sr CurrentUser Certificate store location
-sky signature Key type (use for signing)
I also added an underscore (instead of a blank) in the name; may not be necessary, but my certificate files do not have spaces (these utilities can be odd sometimes).
When you import the CA certificate, make sure you do so into the "Trusted Root Certification Authorities\Local Computer" physical store location. For instance, use this from an Admin cmd prompt:
certutil -addstore -v root "D:\TuyenTk_CA.cer"
These steps worked for me on XP and work today on Windows 7. Hope this helps!
drac
I am new to SSL/OpenSSL and I'm working on Windows 7. I'm trying to configure HTTPS for my ElasticBeanstalk environment following these instructions.
I'm at Step 2 in "Create a Private Key". After I issue the command to generate the key pair:
openssl genrsa 2048 > privatekey.pem
I get:
Generating RSA private key, 2048 bit long modulus
........................................+++
...............................+++
unable to write 'random state'
e is 65537 (0x10001)
However, it does write a key to my directory. But after the second command:
openssl req -new -key privatekey.pem -out csr.pem
I get:
unable to load Private Key
6312:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: ANY PRIVATE KEY
I've tried Googling this a bit, but none of the solutions I've found seem to be relevant for me. I checked the generated key and it looks like
-----BEGIN RSA PRIVATE KEY-----
{lots of characters}
-----END RSA PRIVATE KEY-----
What am I doing incorrectly?
unable to load Private Key
6312:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: ANY PRIVATE KEY
I ran your commands on OS X, and I could not reproduce the results.
I did use the -config option because I have an "OpenSSL server config template" that makes it easy to generate CSRs and self signed certificates:
$ mkdir test
$ cd test
$ openssl req -new -key privatekey.pem -out csr.pem -config example-com.conf
The configuration file is named example-com.conf, and you can find it at How do I edit a self signed certificate created using openssl xampp?. Edit it to suit your taste (in particular, the DNS names).
If interested, here's the OpenSSL man pages on the req sub-command.
I checked the generated key and it looks like
-----BEGIN RSA PRIVATE KEY----- {lots of characters}
-----END RSA PRIVATE KEY-----
You can validate the key you just created with:
$ openssl rsa -in privatekey.pem -inform PEM -text -noout
Private-Key: (2048 bit)
modulus:
00:b0:91:ce:57:28:0f:5c:3a:c3:29:d7:23:6a:71:
ca:64:49:fc:24:ea:69:a3:09:d6:49:94:17:b9:09:
65:fa:5a:10:47:a4:9b:b8:cd:6d:32:74:19:8d:5c:
79:92:f0:a6:43:9c:75:a3:7b:ef:c4:c3:d9:c2:db:
b9:bd:ec:14:a8:b1:52:73:8f:56:c8:5c:16:08:56:
ff:c2:2b:35:3c:0a:0f:34:d0:91:c1:54:7e:72:e8:
97:bf:ea:46:69:5f:e4:21:8d:7a:f5:a5:6b:6a:e8:
00:56:bc:02:f6:b4:ae:6e:89:a6:50:aa:5b:2f:d8:
7d:99:04:61:51:76:b3:5e:9e:30:52:99:54:26:e2:
3a:54:ec:78:34:e6:9a:b7:c2:58:5c:51:3d:39:52:
d4:6e:0c:6e:a1:a0:a5:f1:4d:5a:f5:0b:1a:6e:dc:
f3:bb:0d:d0:53:51:b0:1a:04:ee:86:35:d5:f3:8b:
0d:bc:19:61:6c:0c:b2:7b:a9:7c:47:97:01:bb:a2:
6a:74:d9:19:e9:df:60:07:d4:95:4c:83:f8:3b:84:
c2:b8:3d:b9:a7:34:0a:9b:a3:c6:70:cc:ef:de:f4:
64:88:f1:56:d3:2a:fd:5a:82:88:96:66:93:6c:a0:
b8:ec:e4:4c:e8:76:5c:9c:fc:c4:60:72:b6:9a:3f:
98:a3
publicExponent: 65537 (0x10001)
privateExponent:
00:87:ab:f1:65:ac:e5:68:93:ca:64:3a:e7:fe:a1:
62:c7:7e:c5:dc:c3:b5:d9:cd:f4:36:e3:30:fb:40:
0a:78:bc:7d:67:df:46:bc:50:34:88:a1:07:05:44:
ba:31:ba:f1:b6:5f:e1:50:76:29:bd:02:54:2f:d2:
cf:bc:ec:4a:cf:78:39:07:8c:6b:3d:56:ec:a3:09:
de:49:9f:13:af:87:77:39:b8:cd:56:45:0b:48:56:
0a:4c:2f:c2:5c:b3:8e:c2:6d:48:be:b9:95:79:36:
bd:13:e8:31:4a:c9:78:82:7d:08:2b:51:4a:f1:cf:
a2:6a:52:20:49:0d:31:34:10:88:02:d7:a7:07:70:
32:b5:f5:8c:cc:d4:b2:8d:b9:aa:bb:33:82:1a:74:
bd:4d:4f:e9:e0:cc:f2:27:fb:98:34:2c:77:56:6f:
88:3a:66:32:5d:7d:57:c6:5b:63:39:fa:32:04:9d:
e3:cc:a5:b6:44:91:fd:7d:d1:b6:2d:16:47:59:81:
3d:cf:d9:a7:58:2a:d6:61:5d:c6:69:3b:7a:70:50:
4f:80:f4:d9:fb:c8:7d:5e:44:9e:ac:c8:e6:aa:49:
c3:d6:df:6b:03:68:25:a3:2b:89:8f:9a:35:3a:58:
7d:71:b4:08:d9:04:7b:b9:96:17:f3:a5:19:c5:07:
4e:c1
prime1:
00:d7:d0:d8:8c:b5:86:ed:0e:06:70:c9:54:00:25:
d7:8c:e4:65:51:1b:c5:ba:33:c2:02:1a:dc:80:a6:
ae:8e:1e:e8:c0:b7:04:11:5a:e3:98:52:8f:4a:7a:
43:b8:e8:1b:c8:d6:d3:b2:dc:70:59:a5:ca:83:bb:
35:f1:6c:f5:cb:d0:f4:04:5e:aa:7c:d0:ec:d7:4a:
d5:1c:7c:e2:67:e4:e8:17:95:9b:4e:2b:a0:26:74:
61:d0:a0:15:27:18:e5:84:b5:54:ef:be:82:35:7e:
78:e0:49:6b:4e:ae:93:53:a0:81:a3:8e:de:d3:e5:
dc:c5:ba:03:36:14:47:97:03
prime2:
00:d1:72:3b:f5:34:b1:11:78:b2:79:f4:3e:d7:be:
bf:cc:b3:09:ea:24:a4:cc:7f:64:73:96:d2:48:9e:
55:bc:79:23:c2:d9:80:81:7d:a4:a5:4b:43:33:8e:
62:04:ec:8d:22:d7:43:5e:41:b6:4d:e9:b0:cc:70:
63:17:70:93:88:81:f5:84:a6:3f:2b:98:33:a3:69:
53:11:c7:95:8c:30:ea:e8:58:c7:77:10:b4:a8:f5:
bf:5e:cf:e1:99:bb:b3:4e:57:d2:4c:f7:73:de:8a:
98:8e:7c:26:37:6c:e4:77:c6:d2:ed:5d:53:a7:15:
c3:9c:67:61:d3:24:9a:f5:e1
exponent1:
00:83:34:59:e2:b9:9d:8c:d2:e1:01:82:b4:89:de:
77:bc:15:42:af:5b:c6:0a:dc:da:8e:f3:0b:a9:3f:
2c:92:04:a2:96:3e:ed:bf:2b:55:80:ce:78:84:db:
ed:fe:25:46:77:04:7b:f1:9a:68:c7:67:ae:c6:05:
73:d7:11:da:21:0e:28:bb:db:5d:a4:c2:53:aa:d3:
b8:da:37:e6:61:29:5e:1c:b0:7c:99:ba:96:03:aa:
ef:a8:a9:1a:13:09:e4:c7:98:82:49:ba:b5:68:96:
3a:20:89:22:2e:d4:9d:86:d2:e6:dd:ab:c7:36:65:
e1:a1:67:e3:f9:e5:bc:5c:47
exponent2:
00:81:6d:b9:55:8f:09:39:05:c0:2d:12:dd:5e:cf:
56:91:35:b6:93:c5:af:3d:5c:20:04:3a:18:9a:9d:
95:d7:d1:78:62:e9:ab:ba:d9:9c:cc:34:95:43:9f:
e2:3c:ae:bd:8c:e1:3f:95:58:c0:42:a7:7e:04:e8:
12:a4:22:82:59:22:0e:49:b9:be:61:bf:3d:71:e7:
1d:59:68:5f:a6:f1:77:c8:bb:4c:0f:ec:f7:e7:4d:
6d:c4:36:6c:70:67:08:a8:0a:27:40:3e:ce:90:a0:
4f:24:05:de:4b:f3:f3:bf:7c:d3:4d:b1:95:87:34:
30:dc:4f:1a:a9:b2:fe:3b:a1
coefficient:
6d:51:b3:6e:87:8d:aa:f0:55:c4:22:21:62:a9:ea:
24:b3:b7:91:40:f5:78:5d:f1:40:45:7e:0d:a2:a3:
54:46:ba:42:33:b6:cd:57:a1:85:bc:3d:ba:1c:eb:
87:33:a9:e9:63:1e:7c:2c:89:98:b9:0f:4b:e8:c4:
79:bd:00:6a:f5:3e:ea:63:f1:9e:aa:47:35:5a:22:
fc:4e:e3:61:7e:eb:dc:a6:c0:2c:d5:fd:22:9f:01:
59:32:15:db:41:99:b7:a8:c1:eb:1e:42:c7:1b:c7:
c8:56:86:a8:34:fe:1c:48:b6:6e:f1:c1:5c:96:bf:
9d:fa:e5:4c:d0:2a:d9:09
unable to write 'random state'
This is a well known problem. OpenSSL uses a default configuration file. You can locate the configuration file with correct location of openssl.cnf file.
The default configuration file includes these lines:
$ cat /usr/local/ssl/macosx-x64/openssl.cnf
...
HOME = .
RANDFILE = $ENV::HOME/.rnd
...
To save the random file, you should point HOME and RANDFILE to a valid location. On Windows, you type set HOME=... and set RANDFILE=... in the command prompt. Or better, change it in the OpenSSL configuration file you use.
Also see How to fix “unable to write 'random state' ” in openssl and How do I make OpenSSL write the RANDFILE on Windows Vista?.
I'm trying to configure HTTPS for my ElasticBeanstalk environment following these instructions.
The instructions are wrong in the image below. Do not place a DNS name in the Common Name (CN).
Placing a DNS name in the Common Name is deprecated by both the IETF (the folks who publish RFCs) and the CA/B Forums (the cartel where browsers and CAs collude). You should pay articular attention to what the CA/B recommends because Browsers and CAs come up with those rules, and the browsers follow them (and they don't follow the RFCs). For reference, see RFC 5280, RFC 6125 and the CA/B Baseline Requirements.
Instead, place DNS names in the Subject Alternate Name (SAN). Both the IETF and CA/B specifies it.
The custom OpenSSL configuration file handles this for you. You just have to change the DNS names listed under the section [ alternate_names ]. For example, here's a set of names set up for the domain example.com. Notice there is no DNS name in the CN:
[ subject ]
...
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Example Company
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
Can you check if you have appropriate permissions when you run both the commands? Maybe try doing the same using a user with Admin Rights.
Also make sure the created file privatekey.pem has appropriate permissions before executing the command below (Use chmod if necessary)
openssl req -new -key privatekey.pem -out csr.pem
Submitting this as answer as I don't have enough reputation to comment.
I believe the root of the problem is the error
unable to write 'random state'
e is 65537 (0x10001)
Searching StackOverflow found these results. I would stress that you run the openssl program as sudo or directly as root to avoid any possible permissions issues.
The fix in Windows:
https://stackoverflow.com/a/12522479/3765769
In Linux:
https://stackoverflow.com/a/94458/3765769