I'm trying to get Jira service desk to pull mail from our server but im having certificate issues, I think.
When I try and pull mail from our server Jira pops up
SunCertPathBuilderException: unable to find valid certification path
to requested target
which seems to indicate a problem with the certificate not being trusted. So went off and grabbed a new trusted cert as the old one was self certified for "ES2010" which is the name of the server.
AFAIK the new certificate has been installed but.
It seems like *.domainname.co.uk is where the trusted cert has been issued for is taking precident over owa.domainname.co.uk.
If I goto https://www.digicert.com and check out the cert it seems ok BUT if I use the Portecle app from Jira
Examine the SSL / TLS connection on port 993 (secure imap) it shows as being issued by CN=ES2010
Can anyone kindly help?
Related
I receive the following message after binding our SSL wildcard certificate to our TFS site.
One or more intermediate certificates in the certificate chain are missing. To resolve this issue, make sure that all of the intermediate certificates are installed.
Does the certificate need to authenticate to the internet?
I've added this wildcard cert to other site binding and this is the first time I've seen this message.
How do I resolve this message?
I imported DigiCert High Assurance CA in Trusted Root on both TFS Build and Application server.
I have website hosted on IIS. My main issue is that I want only users with a specific certificate installed to be able to access the site. I tried to follow some tutorials but I can't find anyone covering both server and client side, since I can't get it to work.
I have some questions to the main issue:
What kind of certificate should I use (domain/selfed signed in IIS 7.5)? I do have access to a Active Directory Certificate Services where I can create other types of certificates (CA), but the problem is when trying to import them to my IIS ("certificate cannot be used as an ssl server certificate")
I would like to use a CA certificate, but is that possible when using IIS? Or do I need to write all the code the check if the user has the right certificate?
When created a certificate for the website (e.g. though IIS)..How do I create user certificates that are trusted by the server certificate?
As you may noticed by now I'm not sure how to do all of this, and would really like some help..
Server should use SSL server certificate. This certificate has to have Server Authentication extension in Extended key usage. Server certificate should have SAN extension (Subject alternative name) with domain name of server as DNS name (i.e. somesite.com)
CA certificate has to be imported to Trusted root store (preferably Local Machine) on both server and client machines.
Client certificate should contain Client Authentication extension in Extended key usage.
All EndEntity (client and server) certificates should have CRL distribution point in them where there is URL to CRL that is issued by CA. CRL has to be accessible by both client and server and should be always valid.
You can use XCA for training purposes. It has a nice GUI and it has templates for CA, SSL server and SSL client certificates by default. Then you can mimic these certificates in your Active Directory Certificate Services. Documentation and some guides can be found here.
I'm new to mutual SSL. Therefore my understanding how client certifcates might be wrong.
When using Client certificates in IIS, do they need to be issued from the same certificate (or CA) as the IIS HTTPS binding has configured?
My dev IIS has a self signed certificate.
For the client certificate, I've created a CA and a Client certificate according to
the post here.
The CA is in my "Trusted Root Certification Authorities" of the local Computer.
The Client certificate is in my personal certificate folder.
On IIS I've set Client certificates to accept.
The first strange Thing is that when I browse to my page, the IE always shows me 403.7. Even I've disabled the IE setting "Don't prompt for client certificate selection...", there is no window opening for the certificate selection.
Also when accessing the page with a HttpWebRequest with Client cert attached, the response is always 403. Unfortunately there I did not figure out how to get the sub status.
Why doesn't IIS accept my Client certificate when the RootCA of the Client certificate is in the trusted root store?
Is there a way to get more details where the problem might be?
Thanks
Thomas
Finally could solve the issue:
The CA and Client certificates which I generated according to the tutorial here did NOT have the private key assigned in the certificate store. I had to remove the certificates from the cert store and Import the PFX file including the private key.
Second, the client certificate needs to be in the Current User/Personal store so IE does pick it up. I initallly generated it in the Current Computer/Personal store.
There might be a direct way how to create the two certificates including Private key with makecert. But the PFX import was the easiest way for me.
After 3 days of try and error on my side: If you use IIS10 on Windows2022, TLS1.3 is turned on by default.
The SSL handshake seems not to be implemented correctly in browsers/curls/.... for this case.
For testing reasons turn off TLS1.3
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server
Add:
DisabledByDefault as Dword with 1 and restart the server (not only IIS!)
I have created my SSL certificate using Selssl7.exe on server1 but used Cn as Server2 and hosted the certificate on server2. I started to get a certificate error when browsing from linux firefox saying:
This certificate is invalid, the certificate is not trusted and is self signed, the certificate is only valid for server1
But when I browse the URL from Windows IE I just get the regular error saying that it's not trusted and I can easily add it to exceptions.
Can we use self-signed certificates generated on server1 on a different servers?
You can and you may but you are pretty much undermining each and every aspect of authenticity by doing so.
A self-signed certificate is generally a problem because other users will not know this certificate in advance. So their browser dutifully issues a warning. That's why you have to pay for TLS certificates that will be recognized - they are issued by CAs whose certificates are contained in the default trust store of your browser. CAs had to pay to "be part of the club", but otherwise, anyone can create certificates. It's just the matter of being recognized by default settings.
But you open another hole by reusing a certificate that was issued for a dedicated server on a different server. TLS certificates' subject distinguished names must match the host name of the server they are deployed on. This is mandated by the TLS spec because this is the only effective measure to prevent man-in-the-middle attacks when using TLS. After you open a TLS connection to a server, your code will check whether the host name that you are connected to matches the subject DN of the server's certificate that was sent. Only if it does you can be sure to be talking to the right server.
So, in conclusion, if you reuse a server certificate on a different host, then you are severely impacting the security of TLS. It's still possible, sure, but if you cripple security to this extent, then you are probably better off using plain HTTP in the first place.
I issued a self signed certificate on IIS 7.5, and it is working correctly if i access my website through my computer.
However, if i access the website from another computer, i get an warning saying the certificate was issued to another address.
Is this because the certificate was issued to localhost instead of the actual IP?
Or this doesn't make any sense?
Regards,
The error message you are getting is normal, assuming you do not have anything in your certificate aside from 'localhost' to identify the owner.
Your browser is performing a name check, and looking to validate the certificate that is presented with the URL you typed in. Typically, the common name of a certificate matches the hostname/DNS name of the machine. Alternatively, there can be information inside of the Subject Alt Name (SAN) extension of your certificate. There, you could specify multiple DNS names or IPAddress fields that identify your server in addition to the CN.
If you are simply performing internal testing, I would not be terribly worried about the warning you are receiving. Just keep all of this in mind when you move to production. Also, having your CA being self-signed, you may also receive trust warnings, unless you manually import your self-signed CA certificate into the trust store of the browser you are using.
Maybe this helps you: Self signed certificates on IIS 7. At the end of the article, in the section named "Adding the Certificate to Trusted Root Certificate Authorities", an alternative solution is shown, but it implies importing the certificate in the client machine, so that could be a huge disadvantage. However, it is a solution if you can't register the certificate on a Certificate Authority, an you have access to the client machine.