I keep reading that in an X.509 certificate chain of trust that the “Issuer Name” in a certificate that has been signed by the Issuer must “match” the “Subject Name” of the Issuer’s certificate. Exactly how is this match determined? Do all of the RDNs (Relative Distinguished Names) have to match between both the Subject Name and Issuer Name or is the match determined solely by the RDNs that are present in the Issuer certificate’s Subject Name, or is some other match algorithm at work?
We have a website hosted behind WAF(FortiWeb)and Firewall(FortiGate). The WAF already has the server valid SSL Certificate . Do we need to install SSL certificate on Firewall also to make it more secure ?
Most tutorials on the net only mention sending the digital signature attached to the document, but without the digital signature certificate, it’ll be impossible for receivers to verify the signature. I’m assuming that the digital certificate is somehow sent alongside the signature but I can’t seem to find any source mentioning that.
Please bear in mind that whatever you are trying to use is dependent of mutual support on the server/authenticator and client sides. This is not always trivial to achieve.
Why do I need to trust the server’s certificate if I have the root CA’s certificate installed?
This behaviour is entirely dependent on the client’s implementation (the supplicant). Yes having the server cert signed by the CA should be seen as a significant proof of trust, provided it’s not expired or revoked (if the client checks).
On a windows workstation for example you can either trust CAs specifically or let the user review and accept the server side certificate at the first connection. But if the server side cert is signed by one of the selected CAs, the user doesn’t get a dialog about the cert.
AFAIK the whole point of certificate-based authentication is to prevent MiTM attacks that other methods are vulnerable against.
Conceptually it is instead about mutual authentication, and providing solid proof to the client that the server is being spoofed. It is up to the client to decide what to do with that information. Hopefully and usually it drops the connection. If not, it’s as much at risk of MiTM as if it didn’t use cert based authentication.
There is a username option when selecting the network on the iPhone, which does get matched against a backend SQL database by the freeradius server regardless of that username existing the server accepts the authentication. This page notes that the username is used in inner and outer authentication but to me, that doesn’t seem to make sense as there is no inner and outer identity in EAP-TLS.
Conceptually you could have another EAP authentication dialog within the EAP-TLS channel once that is established. For example EAP-TTLS is often used to protect less secure authentication protocols like PAP. So this is left as an option for the server and client implementations to negotiate through the existing supported protocols and/or custom implementations.
This could also be used for a kind of multi factor authentication whereby a station and a user authenticate separately so that the admin can revoke access to the device or the user independently.
I have Samsung Galaxy S20 with Android Version 10 installed. I have company provided Cisco Access Point at home. The access point is connected to my home wi-fi router.
In phone’s wi-fi settings i see two networks:
MyHome ( My home router wi-fi network)
MyCompany (Access point)
Initially when i setup this phone, i installed microsoft intune app and connected to my company’s portal. After connecting to company’s portal, system automatically downloaded certificates and connected to
MyCompany Access Point successfully.
I accidentally click on Forget Network for
MyCompany, and now i don’t know how to connect back to
Under settings -> Biometrics and security -> Other Security Settings ->User Certificates i see the ceritificate(s) are there, but i don’t know how to use this to connect to
I am running http://clinicianwiki.com, a non-profit website for clinicians to exchange clinical information.
The domain provider of the website is porkbun, which also provides SSL certificate that is downloadable in .pem format.
What are the step I need to take (on the VM and on Azure portal) so that I can use https instead of http (which gives security warning) on the website? Thanks a lot!
I’m getting this same SSL error for weeks and I’ve tried many solutions in the web and none of them worked.
NET::ERR_CERT_DATE_INVALID Subject: *.coupang.com Issuer: Sectigo RSA Organization Validation Secure Server CA Expires on: 2022.3.26. Current date: 2020.6.30 ...
The funny thing about the error is that it gives a DATE INVALID error and yet the error messages show that the certificate has not expired yet. It gives the same error on chrome, IE and edge browser. I tried going to the system settings for time and date and it’s keep on showing me the right date and time.
This error appears on sites that should be able to connect with https; when I use another computer it will be connected easily.
I am surprised that I couldn’t find one concrete example of how to do root certificate rotation. For example:
- Root CA has 2 years validity period
- Intermediate CA has 9 months validity period
- leaf certificate has a 3 months validity period
The renwal/replace time are:
- Root CA is going to be replaced every 1 year
- Intermediate CA is going to be replaced every 6 months
- leaf certificate is going to be renewed every 2 months
- 1 month buffer for service to renew its certificate before the certificate expires.
- 3 months buffer for intermediate CA to sign new service certificate. By the time the old intermediate CA expire, all the old issued certificates are expired as well.
- 1 year buffer to distribute the new root certificates to client. We want to give enough time for clients to pull the new root certificate before the old one expires.
- We have root 1 and root 2 overlapped for 1 year, when should we start signing new CSR using root 2 certificate?
If the one year overlapped time is just for cert distribution, by the time root 1 expired, all clients should already have root 2 trusted. However, by the time root 1 expires, we haven’t signed any new server certificates with root 2. It means when the time root 1 expires, all the services will be down. I guess we will need to ensure all services are using cert from root 2 before we can retire root 1? and we also have to ensure all clients have root 2 key before issuing server certificates using root 2? I think that makes sense but in terms of timeline, how should we managed that? In the 1 year overlapped time, maybe we can do 6 months distribution time, and 6 months signing time. so by the time root 1 retire, everything will be running on root 2 already?
And if we are using private CA, (lets say AWS private CA) , do we need to implement a service to ensure things above will happen?
Given that we own all the clients and servers.
I am getting this Cert error in code, i installed the SSL Cert in IIS and MMC
Provided certificate is not valid for encryption/decryption. There may be insufficient permissions to its private key in the windows certificate store or the certificate itself may not have the correct purposes. If you only want to use it for signing, set the Use property to Signing (CertificateUse.Signing). at xxx.Internet.FBA.CONTROLTEMPLATES.xxx.FBA.IAMRegisteration.Page_Load(Object sender, EventArgs e)
at System.Web.UI.Control.OnLoad(EventArgs e)
at SIMAH.Common.BaseClass.Base.OnLoad(EventArgs e)
I’ve coded my app to use https, but if a https transaction fails for any reason, I assume it’s because the server isn’t configured for https, and thereafter start all transactions with http. Seems like that’s a vulnerability. Likewise, a script kiddie using a proxy to intercept the traffic on his client hardware would be able to make all https transactions fail.
I’m told that if someone tries to MITM your app’s HTTPS request then the request should fail (invalid certificate) and your app should fail with an error, not fallback to HTTP. In a world where SSL is reliably available, sure, but maintaining valid SSL certs is a task in itself. For example, letsencrypt recently revoked some of their certificates and forced renewal of same because of some security problem. Aside from revocations, certs are short term and have to be renewed, and the renewal process involves a lot of stitchware, and can fail. If SSL goes down, I don’t want my site to go dark.
What is the best guidance for either:
More reliably maintaining certificates (such that if they do fail, the resulting downtime falls within the “five nines” SLA unavailability window) without it being such a manual headache, or
Allowing the site to continue to work if SSL has failed? Is it easy to allow most activity to proceed using http, but allow known-critical transactions to require https.
Note that no browsers are involved in the scenarios that concern me.