i did a intranet application and we added a SSL certificate for that application.That certificate is working in Desktop environment but its not working in mobiles.
May i Know whats the problem in certificate?
There exist three most common reasons:
the certificate is issued by the CA that is unknown on the mobile device for any reason (eg. the root certificate of the chain is not listed among the trusted ones on the device).
CA certificate does have one or several levels of CA certificates before the root. In this case you need to include all CA certificates in the chain (excluding the self-signed root) with your server certificate, and ensure that the server sends all of them.
the certificate you use is self-signed and it was previously installed to desktop certificate storage as trusted. Such certificate of course won't be accepted on the mobile device unless/until it's installed as trusted on that device.
Related
I am creating a simple client to connect to the LDAP servers running on one of my windows 2008R2 Active Directory Domain Controllers.
I have successfully connected to the LDAP server over a non TLS connection. However, whenever I attempt to make a TLS connection, the handshake fails. After some digging, and downloading the certificate using the following command:
openssl s_client -connect <domain controller>:636
I found that the certificate being served from the LDAP server is invalid. I can see that the certificate is signed by our CA and my local system, that runs the application already has this trust established with the CA. However, It is missing all of the subject information in the certificate. The client application does not allow for this.
After speaking with the administrator, he indicated that the certificates being generated for the domain controller systems to serve TLS certificates over LDAP is automatic and is created by our internal Microsoft Certificate Server. He was not sure how to address this.
After numerous Google searches, I have come up pretty empty on how to resolve this. Is it something that is addressed on the certificate server? Is it something on the domain controller which is stripping the subject information? Is it some setting or configuration? Since, I do not have direct access to these systems I am at a loss on where to begin.
Any assistance would be appreciated.
Blindly trusting a certificate that is invalid is not an acceptable solution.
Ask your admin to export the root certificate for your environment (like, to a .cer file). Then you can use that file to add it as a trusted root certificate on the computer that needs to access it.
That's how we do it in our environment when we've needed to access an external domain over LDAPS.
Of course, that only works if the application accessing LDAPS uses the Windows certificate store. Some applications, like Java-based apps, don't, and you need to do it another way.
I was able to assist my Admin with updating the template the certificate server was using to include the subject and subject alternate name.
I found the following articles that helped determine the problem
https://blogs.msdn.microsoft.com/microsoftrservertigerteam/2017/04/10/step-by-step-guide-to-setup-ldaps-on-windows-server/
https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx
https://support.microsoft.com/en-us/help/931351/how-to-add-a-subject-alternative-name-to-a-secure-ldap-certificate
Ultimately going over each setting until we found the right solution that solved the problem of why the certificate server was sending and invalid certificate.
Is there a way to set more than one certificate as a device certificate in the SSL Context? I will be having two certificates signed by different trusted CA servers in server SSL. But client can validate only one of them. I am looking for a way to update the SSL context with two certs. I am planning to send both to the clientSSL and the client will check both of these and pick just one of them as server dev cert.
You can't just arbitrarily redefine TLS. The Certificate message only allows one certificate and its authentication chain. See RFC 2246 and successors.
I'm trying to install the preview of Azure AD Connect:
https://connect.microsoft.com/site1164/program8612
During the setup, you can configure the sign-in method for users, synchronization or a federation with ADFS. I want to use ADFS, and I want the setup to configure a new ADFS farm. The setup wants a SSL certificate, so I've made a self-signed certificate and exported it as a .PFX file. However, the setup won't accept the certificate, it states "The certificate is invalid or corrupted. Please try another certificate"
I selected another certificate which I've used for a website, and I get the same result. The certificate chain is OK, I've tried to install the certificate, but no matter what, the setup keeps rejecting the certificate. I can't find any further info in the eventlog or setup log file, and since the Azure AD connect software is quite new and still in preview, there's not much info on the web regarding the installation.
Any ideas on how to make this work?
It is mandatory for AD FS to use a third-party signed certificate. If you don't want to pay for a certificate, you can use one from wosign which is free and publicly trusted (as an intermediate certification authority from VeriSign or similar I think).
I am looking for a solution to my Active Directory problem.
Environment:
Attempting to authenticate users on an external Centos 6.4 website (outside our firewall) by connecting to Microsoft Active Directory which is located behind the firewall.
Currently, we use active directory within our firewall via the domain activedirectory.website.local and works fine. We are in the process of moving some of our sites to an externally hosted server so we need SSL. We have generated a self-signed ssl cert on the active directory server and have exported the ca.pem to the Centos server.
When I try to authenticate Active Directory through the terminal in the client Centos machine (located outside our firewall), I get an error:
TLS: hostname (firewall.website.com) does not match common name in
certificate (activedirectory.website.local)
This error occurs because:
I am trying to access active directory which is behind our firewall from a client computer from outside
the certificate says "Hey I'm generated from
activedirectory.website.local but you are asking for
firewall.website.com".
We talked to an SSL company about getting a commercial SSL for the .local server and they said they could sell us one for a year. Beyond that year they would not be able to extend the SSL due to some sort of regulation.
Due to the complexity of the network, I cannot change the domain name of activedirectory.website.local or firewall.website.com.
I'm sure someone has ran into this problem but I currently can't find any solutions on the web.
All I need from active directory is usernames and passwords for login authentication.
Thank you in advance!
First thing, (shitty ... caca boudin in french) can't you declare activedirectory.website.local with the right IP adress in /etc/hosts.
Another thing I see is to buy a certificate (or to create your own using your own CA) and install it on the Active-Directory service. Have a look to How to enable LDAP over SSL with a third-party certification authority.
All the tutorials i have seen regarding installation of x.509 Certificate assumes that the server machine is your local machine and you have full access to it. But my app is hosted on DiscountASP, so how can I install the certificate on their machine ?
You can't because you don't have permissions to install certificate on hosting server. If you want to use HTTPS you must pay your hosting provider for buying and installing certificate for you (or you must have plan which offers SSL or shared SSL directly). In case of message security (not supported by Silverlight) you can load certificate from file.