I just recently added the SSL Endpoint add-on to my "example" app, and
updated my SSL Cert and Private Key from DNSimple to Heroku (according to this article:
http://ryan.mcgeary.org/2011/09/16/how-to-add-a-dnsimple-ssl-certificate-to-heroku/
) thanks to this command:
$ heroku certs:add STAR_example_com-bundle.pem STAR_example_com-private.key --app example
Adding SSL endpoint to example... done
example now served by oita-4417.herokussl.com
Certificate details:
subject: /OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.example.com
start date: 2012-07-28 02:00:00 CEST
expire date: 2013-07-29 01:59:59 CEST
common name(s): *.example.com, example.com
issuer: /OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.example.com
SSL certificate is verified by a root authority.
But now, when I try to access to my app with https://example.com (and sub-domains such as https://foo.example.com), I have a
warning (inside a big red page, using Chrome)...
How could I fix this? Maybe I have to wait some hours? Thanks!
Related
I have a windows server VM, running server 2019, on a company network, and it is to be used as a web server with Apache. I have got a copy of apache 2.4 installed on it and it serves http pages just fine, but I am trying to set up SSl for https connections.
I have been talked through using the MMC to add the certificates snap in then using this to generate a request. (This is AKA the key file I think?) and sent this file to the necessary admin in the business to provide me with a ceritificate so that the users browsers display a green address bar when visiting the site via https on the company intranet.
They sent me back the following files:
certnew.cer
certnew.p7b
intermediate.cer
root.cer
I then did a lot of googling and found various gides about how to use these files, and I have come to the following conclusions: (please correct if wrong).
Cer files and crt files are the same thing. They can have some kind
of different encoding in the contents, but you generaly use a .cer
file in the same place(s) you could use a .crt file, so if Apache
instructions are mentioning one, I can probably use the other and
just rename the file extension.
The file I sent off was the private key file that I will need to use
in the SSL configuration.
There was some kind of changes between Apache 2.4 and earlier
versions, so I should be carefull when looking at guides about SSL to
ensure it's correct for 2.4 versions.
I need to enable SSL in the main http config file and add the details for my certificate files and server into the httpd-ssl.conf file
The relivant part of that file currently looks like this:
<VirtualHost *:443>
# General setup for the virtual host
DocumentRoot "${SRVROOT}/htdocs"
ServerName <servername>
ServerAdmin <internal email>
ErrorLog "${SRVROOT}/logs/error.log"
TransferLog "${SRVROOT}/logs/access.log"
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. Keep
# in mind that if you have both an RSA and a DSA certificate you
# can configure both in parallel (to also allow the use of DSA
# ciphers, etc.)
# Some ECC cipher suites (http://www.ietf.org/rfc/rfc4492.txt)
# require an ECC certificate which can also be configured in
# parallel.
SSLCertificateFile "${SRVROOT}/conf/primary.crt"
#SSLCertificateFile "${SRVROOT}/conf/server-dsa.crt"
#SSLCertificateFile "${SRVROOT}/conf/server-ecc.crt"
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
# ECC keys, when in use, can also be configured in parallel
SSLCertificateKeyFile "${SRVROOT}/conf/private.key"
#SSLCertificateKeyFile "${SRVROOT}/conf/server-dsa.key"
#SSLCertificateKeyFile "${SRVROOT}/conf/server-ecc.key"
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convenience.
SSLCertificateChainFile "${SRVROOT}/conf/certificate.crt"
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath "${SRVROOT}/conf/root.cer"
SSLCACertificateFile "${SRVROOT}/conf/root.cer"
So I took a copy of the files I had been sent, as well as my key file I sent to them, and renamed them as above so they are refrenced in the ssl config file.
When I try to start the apache service, it fails if I enable SSL in the main http file with a generic error. (but still works fine when i comment out the SSL in the main conf file.) So I then tried to launch the httpd.exe file from a command prompt to get some error that is more helpful, and after running the file with no error responce, I checked in the error logs, and the following lines of errors are shown for my most recent attempt:
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] AH02577: Init: SSLPassPhraseDialog builtin is not supported on Win32 (key file D:/Apache24/conf/private.key)
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] AH02311: Fatal error initialising mod_ssl, exiting. See D:/Apache24/logs/error.log for more information
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] AH02564: Failed to configure encrypted (?) private key <servername>:443:0, check D:/Apache24/conf/private.key
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] SSL Library Error: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] SSL Library Error: error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error (Type=PKCS8_PRIV_KEY_INFO)
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] SSL Library Error: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] SSL Library Error: error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] SSL Library Error: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] SSL Library Error: error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error (Type=RSAPrivateKey)
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] SSL Library Error: error:04093004:rsa routines:old_rsa_priv_decode:RSA lib
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] SSL Library Error: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag
[Sun Oct 30 15:06:02.661255 2022] [ssl:emerg] [pid 3484:tid 512] SSL Library Error: error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error (Type=PKCS8_PRIV_KEY_INFO)
AH00016: Configuration Failed
I don't really know what any of that means, but I'm guessing it's teling me there is something wrong with my private key file, but I have no idea how to tell what is wrong or how to fix it. I have checked that the modules for ssl are enabled in the main apache conf file.
Can anyone provide any guidence?
Thanks.
Meta: this Q is not programming or development and is arguably multiple questions, but this semi-A is much too long for comments. I will delete (or agree to a mod deleting) if needed.
request ... is AKA the key file I think?
Absolutely not, and I think this is most of your problem. The whole security of 'public-key' cryptography, also called 'asymmetric', is based on you not ever sending, giving, or otherwise providing your private key to anyone else.
The 'request' is a CSR and is basically temporary; once the certificate is issued the CSR is no longer needed or used. If you want to be tidy, you could delete it.
users browsers display a green address bar
The green bar was only for Extended Validation (EV) certificates, which from real public CAs cost quite a bit of money. It's possible your company has tweaked all the PCs (or all the relevant ones) to accept an internal or ad-hoc CA as valid for EV, but I don't see why they'd bother, as browsers dropped the green bar several years ago. What you get now is a padlock on the URL/address bar for HTTPS with any valid certificate (regardless of validation class), and for an invalid certificate you get either a warning/error icon modifying or replacing the padlock and/or a complete warning/error page.
Cer files and crt files are the same thing ... I can probably ... just rename the file extension.
Kind of. There are two main encodings used for a (single) certificate in a file and some other places: DER also called binary, and PEM also (and incorrectly) called by Microsoft base64. People variously use both extensions .cer .crt (and sometimes others as well) for both formats. Much software can use both, but httpd can only use PEM -- in a file with any name or extension, even FeeblyGorp.snork if that's what you want.
However, an HTTPS server actually needs (in addition to the privatekey) not just a certificate but a chain consisting of several (almost always at least 2, and usually 3 or 4) certificates. There is more variation in handling such a chain. The simpler way is just to take the certificates and concatenate them. Another way that developed in the past and is still used is a particular type of PKCS7 message which conventionally has the extension .p7b or .p7c (although again most programs can handle any name, in spite of Microsoft persistently trying to make you believe a filename's extension somehow controls the content, which it does not and never did). Apache supports only the plain-sequence in PEM method, not the PKCS7 method.
The file I sent off [the CSR] was the private key file
No. See above.
There was some kind of changes between Apache 2.4 and earlier versions, so I should be carefull when looking at guides about SSL to ensure it's correct for 2.4 versions.
There are changes not just between the 2.2 and 2.4 'families', but between point releases within 2.4. Search the documentation for "version 2.4." to see. If you try to use something that is newer than the version you are running it will almost certainly give an error message, but if you use an older feature it will still work on newer versions with very rare exceptions.
I need to enable SSL in the main http config file and add the details for my certificate files and server into the httpd-ssl.conf file
Not really. httpd reads one config file initially, and if that file contains one or more <Include> directives referring to other files it reads them also; I expect that is what you mean by 'enable SSL in the main config file' -- you're not enabling SSL as such, you're using a file that happens to provide SSL configuration. httpd can handle all the config in one file just fine, but people often find it more convenient to put logical 'pieces' such as different vhosts, or in your case the SSL config, in separate files that can be named to reflect each one's contents. In short, you must add the SSL related config, but you aren't required to put it in a separate file with a specific name.
So, net, your problem is that you need the privatekey in a file usable by httpd, meaning one of a few PEM formats. When you create a certificate request with MMC/cert it stores the privatekey within the Windows certificate store in a hidden location; normally when you get the resulting cert from the CA you load it into the same store with MMC and it is matched up with the hidden privatekey so that Windows-specific programs like IIS can use both of them together. Once you do that it may be possible to export the privatekey with the cert as a PFX/PKCS12 file, which httpd cannot use directly but which can be converted to suitable PEM file(s) using OpenSSL if you have or get that. However, if the key is marked unexportable, you're out of luck.
The usual (and simple) way to get a cert for httpd is OpenSSL: it can create the privatekey in a PEM file and the CSR, and when you get back the cert (and chain) you just combine them with the privatekey you already have.
I'm experiencing a somewhat perplexing issue with a self-signed SSL certificate that Windows recognizes as valid, but which no modern browsers will accept.
The certificate is present in the system certificate store (accessed via the Certificates snap-in in MMC), within both the Personal and Trusted Root Certification Authorities folders, and marked as valid.
Per the utility SSL Certificate Verifier, the certificate and certificate chain are valid.
Here is its output:
**************************************************************************
Processing 'localhost'
**************************************************************************
Scan started: 21-09-2020 13:43:33
Generating connection string...
Connection string is: https://localhost:14006/
Entering certificate validation callback function...
Server returned 1 certificates.
Entering server certificate chain validation function...
Leaf certificate issued to: E=REDACTED, CN=localhost, O=localhost, L=New York, S=NY, C=US
Found Subject Alternative Names extension in the certificate.
Fetching SAN values:
DNS Name=localhost
DNS Name=127.0.0.1
DNS Name=::1
IP Address=0000:0000:0000:0000:0000:0000:0000:0001
IP Address=127.0.0.1
Certificate chain successfully passed all checks.
Finished!
Scan ended: 21-09-2020 13:43:33
If I attempt to access the service using Internet Explorer or curl, I get the expected 200 result from the service.
However, if I try to access the service using Edge, Chrome, Opera, or Firefox, I get ERR_CONNECTION_RESET. Before adding the certificate to Firefox's certificate store, I got PR_CONNECT_RESET_ERROR but now that also throws ERR_CONNECTION_RESET.
There are no proxies or VPNs active on my system or anything else that would interfere with Windows' networking. I'm at a complete loss. What on earth is happening here and how do I go about fixing it?
I had exactly the same symptoms - IE and curl working. Chrome, Edge and Firefox not, all reporting ERR_CONNECTION_RESET.
Ultimately it was pinned down to a corrupt HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\Functions key.
nmap reported a single cipher in use when it was broken:
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
Reloaded the key with a correct value:
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
The absence of the GCM ciphers is the likely cause, given Chromium was reporting them as obsolete five years ago.
I had a similar problem on chrome where it said
NET::ERR_CERT_COMMON_NAME_INVALID
, turns out the error was with the certificate itself.
Try the to create a certificate with the below link:
SSL Certificate
In my webpack.config.js file, I added https configuration:
devServer: {
historyApiFallback: true,
contentBase: './',
https: true
}
Then I receive an error when I navigate to https://localhost:8080/
Your connection is not private
Attackers might be trying to steal your information from localhost (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
Subject: webpack
Issuer: webpack
Expires on: Dec 10, 2015
Current date: Mar 27, 2016
PEM encoded chain: -----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE----
It appears webpack's certificate expired. Did I configure something incorrectly? Or have I misunderstood SSL?
I'm using
"webpack": "^1.12.9",
"webpack-dev-server": "^1.14.1"
EDIT:
As pointed by Markus in the comments, webpack-dev-server generates the certificate automatically since version 2.5.0.
OLD ANSWER:
The problem is that the self-signed certificate of webpack-dev-server expired. This has been fixed in #436.
I've just downloaded wampserver with Apache/2.4.4 (Win64) OpenSSL/1.0.1g PHP/5.4.12. Not a standard download, the original openssl version was too old.
I'm trying to create a new soapclient, but when the wsdl is at an ssl url apache crashes with no error.
$wsdl = 'https://www.undisclosedlocation.com/wsdl/mywsdl.wsdl";
$sclient = new SoapClient($wsdl,array('trace'=>1));
no hits, no runs, no errors. All i get is:
The connection was reset
The connection to the server was reset while the page was loading.
on the browser. Even in my debugger i just "session prematurely finished"
The wsdl isn't available on a url without ssl, but if i copy it to a local location it works, but then all the namespaces are off.
I'm using a self-signed certificate and get one more error.
[Sun Apr 13 22:45:50.192400 2014] [ssl:warn] [pid 19:tid 76] AH01909: RSA certificate configured for mydomain:443 does NOT include an ID which matches the server name
It seems that the problem is with your certifcate. There are at leas two problems:
Self signed certificate, which is not trusted by your client
The certificate doesn't contain the DNS name of your website
Most of the systems will discard the connection when one of those errors occurs.
Try to add the following setting before:
$context = stream_con**strong text**text_create(array(
'ssl' => array(
'verify_peer' => false,
'allow_self_signed' => true
)
));
See the following Stackoverflow question: Disable certificate verification in PHP SoapClient
When deploying an APNS certificate in a .wlapp file in MFP 7.0, I'm seeing a null-pointer exception when it validates the end-date, even though it has one. ( openssl pkcs12 -in apns-certificate-sandbox.p12 | openssl x509 -noout -enddate returns a valid date in the future).
It seems others have made this work, so I'm guessing it must be something I am doing wrong...has anyone else resolved similar issues with valid Apple Push Notification Service certs failing to be deployed on MFP
Relevant lines from the log:
947: "com.ibm.worklight.admin.services.ApplicationService E FWLSE3000E: A server error was detected.",
"948: com.ibm.worklight.admin.common.util.exceptions.ValidationException: FWLSE3119E: APNS certificate validation failed. See additional messages for details.",
"949: at com.ibm.worklight.admin.util.PushEnvironmentUtil.validateApnsConfiguration(PushEnvironmentUtil.java:232)",
"950: at com.ibm.worklight.admin.util.PushEnvironmentUtil.validatePushConfiguration(PushEnvironmentUtil.java:220)",
[ ... lots more trace here .. ]
"1030: Caused by: java.lang.NullPointerException",
"1031: at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:117)",
"1032: at com.ibm.worklight.admin.util.PushEnvironmentUtil.getCertificateExpiryDate(PushEnvironmentUtil.java:362)",
"1033: at com.ibm.worklight.admin.util.PushEnvironmentUtil.validateApnsConfiguration(PushEnvironmentUtil.java:230)",
Initial hurdle was that the .wlapp file was not being built, so no apns certificate was in the file (it is just in .zip format with a meta directory that should hold the .p12 file). The underlying issue was that the tag's password field in application-descriptor.xml wasn't exactly right: it was following the example from "Push Notifications in iOS applications" at https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/notifications/push-notifications-native-ios-applications/ :
<pushSender password="apns-certificate-p12 password"/>
when it really should just have the password:
<pushSender password="password"/> </code></pre>
with the file named either apns-certificate-sandbox.p12 or apns-certificate-production.p12 depending on which server is to be used.
Double dumbass on me for not checking the official docs at http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.dev.doc/devref/c_the_application_descriptor.html , which has it described correctly.
Moral: "When in doubt, RTFM"