there
When using spring boot admin to monitor my local ssl app. it always show me the error "No name matching localhost found".
I enabled ssl communication both of my local ssl app(as admin client) and admin server app.
and admin client was successfully registered at the admin server.but once the client registered at the server. it always show the error "General SSLEngine problem" "No name matching localhost found".
I am sure that I added the client certificate as truststore to the server and added server certificate as truststore to the client. so I don't know why that error happened, can you guys give some advice? Thanks
Both sides(server, client)' public certifications need to be imported to each other.
Note: the public certification of client needs to be imported to JDK cacerts as well.
Related
I am trying to access the repository from a standalone java application using JcrUtils.
**repository = JcrUtils.getRepository("http://localhost:4502/crx/server"); this works**
**repository = JcrUtils.getRepository("https://localhost:4502/crx/server"); this doesn't work**
Exception in thread "main" javax.jcr.RepositoryException: Unable to
access a repository with the following settings:
org.apache.jackrabbit.repository.uri: https://localhost:4502/crx/server The following
RepositoryFactory classes were consulted:
org.apache.jackrabbit.commons.JndiRepositoryFactory: declined
org.apache.jackrabbit.core.RepositoryFactoryImpl: declined
org.apache.jackrabbit.jcr2dav.Jcr2davRepositoryFactory: declined
org.apache.jackrabbit.jcr2spi.Jcr2spiRepositoryFactory: declined Perhaps the repository you are trying to access is not available at
the moment. at
org.apache.jackrabbit.commons.JcrUtils.getRepository(JcrUtils.java:223)
at
org.apache.jackrabbit.commons.JcrUtils.getRepository(JcrUtils.java:263)
at com.hero.jcr.util.CqHelper.getSession(CqHelper.java:20) at
com.hero.jcr.commandline.CheckConnection.getDamAssets(CheckConnection.java:36)
at
com.hero.jcr.commandline.CheckConnection.main(CheckConnection.java:29)
Thanks in advance
The problem can have different causes.
HTTPS configured and on which port
It looks like you're trying to access http and https in the same situation on the same port. Http and Https don't run on the same port in parallel.
Please use the SSL Wizard as hinted by ronnyfm to check if SSL is activated and on which port it is used: https://docs.adobe.com/content/help/en/experience-manager-65/administering/security/ssl-by-default.html
For instance the default port for https in AEM is 8443, so try https://localhost:8443 to access it, if you have configured it there.
Untrusted Certificate
Also connecting to https might not work if you use an untrusted certificate, which you need to add to the Java security keystore first. In my case I got the same "Unable to access" message, because the original exception regarding the certificate got silently swallowed in the JCR library I was using.
Wrong certificate
When you added the certificate to the keystore and it still doesn't work, check if the certificate was created for them same host you request. If you created it for bla.host, but try to access it via localhost, it also gives you the same exception, while the original message is silently swallowed.
I am trying to wrap my head around how this should be set up correctly. I have two certificates, a client certificate and a service certificate. I've placed these in the MMC, on the service account for the host instance that handles the send port. So the client certificate is placed in the Personal folder and the service certificate is placed in the Trusted People folder.
I've tried using several "Find" methods to locate these certificates, such as thumbrprint and serial number, but I always get a "Certificate not found" exception back.
My current settings on the adapter.
Client certificate:
Service certificate:
My settings for Authentication:
SSL Certificate Authentication settings:
What is the correct way to add the certificates to the different stores, so that they can be located by Biztalk? I've found the MSDN documentation on the topic, but it doesn't really provide any answers: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/wcf/clientcertificate-of-clientcredentials-element
You have to be logged in as the BizTalk Service Account to manage Certificates. Run As doesn't typically work.
Other than that, the instructions should be correct.
I am trying to access a Filezilla Server using FtpWebRequest in Powershell, like this:
$ftprequest = [System.Net.FtpWebRequest]::Create($sourceuri)
$ftprequest.Method = ([System.Net.WebRequestMethods+Ftp]::ListDirectoryDetails + " -a")
$ftprequest.Credentials = New-Object System.Net.NetworkCredential($username,$password)
$ftprequest.EnableSsl = $true
In Filezilla Server there is a "Generate New Certificate" which is what I used to create the certificate. This created a .crt file that Filezilla is pointing to for both the private key and certificate file.
The server is also configured with the options "Enable FTPS" and "Allow explicit FTP over TLS".
I am able to happily access the server using the Filezilla Client (although it warns that the server's certificate is unknown).
To access the server from a Powershell client, without getting complaints about the certificate, my understanding is the best thing to do is import the certificate on the client machine. I managed to do this by downloading the .crt file, manually stripping out the private key portion using Notepad, and then running:
Import-Certificate -FilePath .\filezillaCertificate.crt -CertStoreLocation cert:\CurrentUser\My
However, trying to connect using FtpWebRequest I still receive the error "The remote certificate is invalid according to the validation procedure."
Can anyone point me in the right direction?
This is not a PoSH issue. It is a pure PKI 101 (cert implementation) issue.
Self-signed certificates will always be considered untrusted in most cases, because there is no way to validate it, no public registered body for it and no public CRL (Certificate Revocation List / Authority) associated with it.
You cannot create a PKI cert for a remote location on your local machine. You must create the cert on the remote location, or buy a public cert and install it on the remote location certificate store. The public and private key must reside on the remote server / site. For any server / site, the certificate must be registered / issued to that server then manually assigned to a site (FTP/s, HTTP/s).
Then, you download the public cert from the destination and install that on your local machine. Normally installed to the local machine store. If you cannot download that public certificate and certificate chain using a browser, by clicking on the lock, after visiting the site, then you must request that the destination server/site owner send you the public cert for you to install locally. Again, normally installed to the local machine store.
I know your post is about a Filezilla server (Full Disclosure: I've never seen on used one), but the approach as shown in the articles below on setting up FTP over SSL on IIS should be similar.
FTP over SSL
The element specifies the FTP over Secure Sockets Layer (SSL)
settings for the FTP service; FTP over SSL was first introduced for
IIS 7 in FTP 7.0.
Unlike using HTTP over SSL, which requires a separate port and
connection for secure (HTTPS) communication, secure FTP communication
occurs on the same port as non-secure communication. FTP 7 supports
two different forms of FTP over SSL:
https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/site/ftpserver/security/ssl
https://learn.microsoft.com/en-us/iis/publish/using-the-ftp-service/using-ftp-over-ssl-in-iis-7
Update to find the FileZilla SSL guidance
Install a SSL certificate on FileZilla FTP Server
https://www.tbs-certificates.co.uk/FAQ/en/FileZilla_FTP_Server.html
Installing a certificate on an OpenSSL-based server is really similar
than doing so on Apache: Install an Apache certificate, except that
the instructions indicating the path to th files are not the same!
for FTP FileZilla server, via the interface: FileZilla Server
Option -> SSL/TLS settings:
•import the private key (.key file generated along with the CSR) in
"Private key file".
•import the certificate and the certification chain in the same file:
1) on your certificate status page, download the "file.cer" file and
the certification chain "chain-xxx.txt" 2) concatenate those two
files into one 3) import the file in "Certificate file"
How to connect FTP over SSL/TLS in FileZilla?
Create Site
Go to File >> Site Manager >> New Site.
Following are the required details to fill up.
• Host: Enter Hostname(i.e. ftp.yourdomain.com) or IP address which we
have sent in Welcome e-mail. • Port: 21 (Default FTP port is 21, you
can also keep it blank). • Protocol: FTP - File Transfer Protocol. •
Encryption: Select Required explicit FTP over TLS from dropdown list.
• Logon Type: Select Normal from the dropdown list. • User: Your FTP
username. • Password: Your FTP Password.
https://manage.accuwebhosting.com/knowledgebase/761/How-to-connect-FTP-over-SSLorTLS-in-FileZilla.html
The FileZilla wiki also talks to how to do the SSL implementation.
In order to secure my Rest Services, I have enabled SSL in IIS and Created a Self-Signed Certificate and assigned it to the HTTPS binding in IIS. I exported the same as pfx file and added the same in IE also but when I try to access the Services, I get the following error on Windows 7, Enterprise edition
HTTP Error 403.7 - Forbidden
The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
And on Windows Server 2003, this is
HTTP Error 403.7 - Forbidden: SSL client certificate is required.
Internet Information Services (IIS)
I am not sure what shall I do except adding the certificate in IE under “Personal” and “Trusted Root Certification Authorities”? Could you please suggest me some step, in order to make this work.
Note: I have tried with “Self-Signed Certificates” as well as with Certificates generated from Microsoft “Certificate Services” also.
Any help is greatly appreciated.
SSL is used to verify the identity of the server, not the identity of the client. The error suggests (http://support.microsoft.com/kb/199215, "This is used for authenticating you as a valid user of the resource. ") the server wants to identify the client. Which of the two are you trying to do?
Edit: SSL requires the public part of the SSL certificate to be available to the client. Adding it to the trusted root certificates seems to me to be the only way to make the public part of a self-signed certificate available to the browser.
I've godaddy's 2048bit certificate for domain and 4 subdomains.
[www.site.com, mail.site.com, e.t.c.]
Standard Multiple Domain (UCC) SSL Up to 5 Domains - 1 year (annual)
That certificate works fine in Apache, ssl web checker says OK and browser shows green line in address string.
I've added this certificate to mail daemon, it has been accepted by Exim too.
When some client tries to send mail with SSL/TLS connection through mail server, mail program says "Certificate is BAD" though shows correct trusted info.
Client connects to hostname: mail.server.com, server's hostname is: ns1.server.com (not added to certificate), mail server says: 220 ns1.site.com ESMTP Exim 4.73
Mail clients tested: iPAD mail client, Mozilla Thunderbird, Mac mail client
Please help.
UPDATE:
Godaddy's ssl checker says: SSL Chain of Trust is Broken!
Here are a couple of things to check:
Is the hostname that the mail client uses in the TCP connect, listed in the server certificate as the Common Name (CN) of the subject distinguished name?
If not, is it listed using type "DNS:" in the Subject Alternative Name X509 v3 certificate extension?
If neither of the above, you might be getting "Remote Certificate Name Mismatch" (or similarly named error.)
If it is listed, then look for the Issuer of the certificate, and Issuer of the Issuer, etc., all the way to the root certificate of the chain. The root certificate should be installed on the client machine, in the "Trusted Root" certificate store for whatever client you are using (Windows, Mozilla, Java keystore, etc.)
If the root certificate is installed, then look at the intermediate certificates, if there are any in the chain (between root and server certificates). They have to either be installed locally, or arrive from the server alongside the server certificate -- either the server sends them each time or you've got the intermediate certificates already installed on the client end. Either way, they have got to be in hand to accept the server certificate.
Do the clients which reject the certificate have the appropriate root certificates in their cert store?