-
Notifications
You must be signed in to change notification settings - Fork 700
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
added the ability to renew certs and view their expiration dates #1461
Conversation
I like the idea. And I follow your thinking in terms of the 60-days and 368-days. That said, I suspect most devs don't care what the expiration date is on local certs, they just want them to never expire. Thus, I'm wondering what your thoughts are on defaulting the |
Would it also make sense to call |
In the past I've simply run |
So I just made this change, and I had to authenticate (TouchID, thankfully) each site's new certificate. I can see how this would be annoying to do every time. However, this would likely only be run once a year. Although, I did enjoy the simplicity of removing the days option on the renew command. |
This makes me a little sad, as it doesn't really test/document the behavior of the renew command.
Ya, I haven't found a way to "batch-authenticate" (jump into sudo once for the whole group) from the CLI yet, since MacOS 11. |
I've not gone looking for the answer myself, but it feels like we shouldn't have to trust the individual cert if the CA is trusted. I'm fairly certain we could skip trusting the cert, but I would have to test and check. Do you know the answer off the top of your head? |
I believe what's triggering the password prompts is the registering of the certs into the keychain. Not sure that can be skipped. |
Yeah, that is what is triggering it. I think as long as the CA is trusted, that's unnecessary. I'll try to spin up a clean environment this weekend and test it. If I confirm it's optional, I will come up with a way to make it skippable via a parameter so we can only skip it when it running renew. That way, existing behavior is unchanged. What do you think? |
If it's optional, then let's bypass it by default ... cuz it's really unfriendly to be prompted a dozen times unexpectedly. I'm noting that there are several places that handle certs: valet |
@mattstauffer I think this PR is ready for review and merge if you're okay with it. |
Yah, I'd love to look at that separate PR about how sites are registered. Looking forward to that. For now, reviewing this. |
$sites = collect(Site::secured())->map(function ($url) { | ||
return ['Site' => $url]; | ||
}); | ||
$app->command('secured [--expiring] [--days=]', function (OutputInterface $output, $expiring = null, $days = 60) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This whole refactored method is very clean and readable. Nice work!
A reasonable default is set here, consistent with the default set in other places. Fixes laravel#1464 Updates laravel#1461
I was helping a teammate today resolve an issue with a certificate issue locally. After discovering the cert had expired, I thought it might be nice to expose certificate expiration dates when listing secured sites. It would also be nice to be able to renew those certs.
This PR adds both of those features.